Closed GoogleCodeExporter closed 9 years ago
Hi Kapak
Sound like a fairly big issue.
First, a few questions, just to be sure :
- Version 1.5.0 mentioned in the report is the version of LZ4 library, hence
latest one ?
- LZ4_compressHC & LZ4_decompress_safe() don't provide any header information.
Therefore, compressed & uncompressed sizes must be transmitted independently.
It's not part of data to decompress.
Is this part clear ?
(It seems fine because 2. decompression on x86_64 works fine, but I'm a bit
worried by this sentence : first 4 bytes is uncompressed size)
- How is read header information on iOS platform (compressed & uncompressed
size) ?
Did you verify they were properly interpreted ?
(very small risk of endianess issue, since ARM are bi-endian)
Are you sure you don't provide the size within the flow of data to decompress ?
- Any possibility to have access to one problematic sample for debugging ?
Regards
Original comment by yann.col...@gmail.com
on 18 Feb 2015 at 11:07
hello,
I've spent few hours in debugging since I wrote this issue and problem was
somewhere else. In this expression:
out_buf = malloc(original_size);
..
return [[NSData alloc] initWithBytesNoCopy:out_buf length:original_size
freeWhenDone:true];
I missed "freeWhenDone:true" and iOS fall early into undefined behavior.
Sorry for blunt. You can close this issue.
Original comment by capa...@gmail.com
on 19 Feb 2015 at 6:43
sure
Original comment by yann.col...@gmail.com
on 19 Feb 2015 at 4:18
Original issue reported on code.google.com by
capa...@gmail.com
on 18 Feb 2015 at 9:40