andikleen / snappy-c Goto Github PK

Everything is in the title :)

@andikleen I wonder how snappy supports unaligned access under ARMv5? compat.h defines get_unaligned and put_unaligned as no-op:

#define get_unaligned(x) (*(x))
#define get_unaligned_le32(x) (le32toh(*(u32 *)(x)))
#define put_unaligned(v,x) (*(x) = (v))
#define put_unaligned_le16(v,x) (*(u16 *)(x) = htole16(v))

I'm getting SIGBUS error in verify if I compile snappy for Android with -mthumb (google recommends to compile code with it). It happens due to unaligned LDMIA instruction. It happens on line UNALIGNED_LOAD32(s2) == UNALIGNED_LOAD32(s1 + matched)) { in snappy.c::find_match_length. Note: error happens only with -O2 gcc flag, with -O0 code works fine.

Also verify works fine if I remove -mthumb from CFLAGS. However I'm not completely sure whether gcc generates code in this case, or it works fine just because I'm testing on ARMv7 processor (which partly supports unaligned access, eg., LDR can be unaligned, however LDM should be aligned).

I'm using sources from https://github.com/pakhuchiy/snappy-c/tree/android and compile with gcc-4.6 from NDKr9.

on line 157, it tries to deallocate a string (called "file") it shouldn't deallocate, causing a SIGSEGV
I guess the author might have probably wanted to free something else?

int main(int ac, char **av)
{
/*
  . . .
*/
	free(file);  // I think it shouldn't deallocate "file"
	free(out);
	
	return err;
}

scmd than crashing with out of memory error

A number of the files in snappy-c have no license statement. Also there is no overall license file. This will inhibit its adoption because it creates legal ambiguity. Hopefully this could be licensed under the same BSD style license as the original project?

recipe for target 'snappy.html' failed
When I run make html, it shows:
/home/sysy007uuu/Downloads/snappy/kernel-doc -html snappy.c > snappy.html
Makefile:32: recipe for target 'snappy.html' failed
make: *** [snappy.html] Error 1

When updating librdkafka's copy of snappy-c from 711c52b to 8015f2d snappy compression stopped working for me.
Since librdkafka uses the SG/iovec interface I turned to sgverify to see if there's been a regression.
It turns out I can't run sgverify succesfully on the latest master, it always fails with a large number of error messages, like:

$ ./sgverify ./sgverify | head
uncompression of ./sgverify failed: Input/output error
compressed sg 0 does not match
46480: 0 vs 8b
46481: 0 vs 10
46482: 0 vs 31
46483: 0 vs c0
46484: 0 vs e8
46485: 0 vs d7
46486: 0 vs fa
46487: 0 vs ff
....continues...

After a bit of git bisect I found that due to bad handling of snappy_uncompress_iov() return value errors were not really reported by sgverify before version ec2b3ca.

Which leads to the question: did sgverify ever work?
Maybe I'm just not using it right.