Segmentation fault on inflate() after an inflateSync() running into a partial flush sync point

[Kenny_Peng]

I'm running into a problem with the IPP zlib wrapper where if I try to call inflateSync() on a file that has fake flush points (i.e. partial flush sync points, not full flush sync points), the subsequent inflate() call will cause a segmentation fault. I have a small test program that shows this and the compressed file that it works on.

The compressed file was generated using:

for i in {1..250000}; do echo $i >> compress.txt; done
gzip --rsyncable compress.txt

The --rsyncable option tells gzip to insert flush points for rsync-friendliness, but these flush points are partial sync flush points, as opposed to full flush points (http://newsgroups.derkeiler.com/Archive/Comp/comp.compression/2006-02/msg00327.html).

When linking against the regular zlib implementation, calling the inflate() after the inflateSync() produces Z_DATA_ERROR, which is consistent with Adler's comment in the link. When linking against the IPP zlib implementation, the code segfaults before returning anything for inflate().

One interesting thing I noticed was that when setting the TEST_SIZE to 1, the IPP will not segfault and will eventually register Z_DATA_ERROR as well.

Just some information about my setup: I'm using IPP 7.0 on x86_64 Ubuntu Maverick (10.10), compiled the libipp_z.so without multithreading support (removed the MT variable assignment in the build_intel64.sh). Thanks in advance for any help.

[PaulF_IntelCorp]

Hello Kenny,

I will ask our engineering group to take a look and see if they can identify the source of the problem.

Regards,

Paul

[PaulF_IntelCorp]

Hello Kenny,

I received some information from engineering regarding this issue. It is a previously identified bug that they successfully fixed in the 32-bit version, but have not completely eradicated in the 64-bit version. The 64-bit fix will not likely be available until the 7.0.3 release, which would most likely occur 2-3 months from now.

If you are able to use the 32-bit edition of the library in your application, that is the best solution for now. The performance difference between the 32-bit and 64-bit variants of the IPP_ZLIB library is very small, so there is not a big penalty for using the 32-bit variant in a 64-bit system.

Regards,

Paul