- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page