Re: [Openexr-devel] Issue with libz library 1.2.x version and OpenEXR

[Florian Kainz]

Hi Jeff,

Can you send me a test case?  I don't have access to Fedora Core 4,
but if I had the image that causes the segfault, together with the
relevant parts of your image writing code, I might be able to reproduce
the problem.  (Writing the image using PIZ compression works, right?)

About two weeks ago, I ran the OpenEXR confidence tests and the
programming examples (IlmImfTest and IlmImfExamples) through valgrind.
Here's my machine's configuration: 64-bit Suse Linux, zlib 1.2.2,
HP xw9300 workstation with AMD Opteron processors.

Everything checked out fine, except for a "conditional jump or move
depends on uninitialised value" somewhere in zlib.  As far as I can
tell, there is nothing wrong with the arguments the ZIP compressor
passes to zlib.

The FAQ page (http://www.zlib.net/zlib_faq.html#faq36) on the zlib
web site says:

    Valgrind (or some similar memory access checker) says that
    deflate is performing a conditional jump that depends on an
    uninitialized value. Isn't that a bug?

    No. That is intentional for performance reasons, and the output
    of deflate is not affected. This only started showing up recently
    since zlib 1.2.x uses malloc() by default for allocations,
    whereas earlier versions used calloc(), which zeros out the
    allocated memory.

I wonder if whatever it is that zlib does when it branches based
on an uninitialized value conflicts with some compiler optimization?

Florian



Jeff Clifford wrote:
> Hi,
>
> I have successfully compiled up 32 and 64-bit versions of the openEXR 
> libs for our 64-bit Fedora Core 4 machines.
>
> The libraries have been working fine until I used ZIP compression when 
> writing a file.  This caused a seg fault at the line:
>
>    file.writePixels( header.dataWindow().max.y - 
> header.dataWindow().min.y + 1);
>
> Suspicious of an error else where in code I ran the program through 
> Valgrind to check if they were any other causes and where exactly the 
> problem was.  There were no other errors, just this:
>
> ==8576== Invalid write of size 2
> ==8576==    at 0x342FE0582B: (within /usr/lib64/libz.so.1.2.2.2)
> ==8576==    by 0x342FE0478E: deflate (in /usr/lib64/libz.so.1.2.2.2)
> ==8576==    by 0x342FE025BB: compress2 (in /usr/lib64/libz.so.1.2.2.2)
> ==8576==    by 0x55C08B: Imf::ZipCompressor::compress(char const*, int, 
> int, char const*&) (in /u/jbc/tools/bin/Linux64/exrwriter)
> ==8576==    by 0x5557B7: Imf::OutputFile::writePixels(int) (in 
> /u/jbc/tools/bin/Linux64/exrwriter)
>
> If I change the line
>
> header.compression() = Imf::ZIP_COMPRESSION;
>
> to any other compression (except ZIPS) or no compression everything 
> works fine.
>
>
> I then decided to check what version of the zlib came on the 32-bit 
> RedHat9 machines machines which worked fine with no seg fault (1.1.4).
>
> First off I tried upping the zlib version to 1.2.3 (the latest release) 
> but still the seg fault occured.
>
> I then rolled back the version of zlib on our Fedora Core 4 machines to 
> 1.1.4 and the seg fault stopped.  I found that rolling back both the 
> 32-bit and 64-bit versions of the zlib library fixed both the 32-bit and 
> 64-bit verions of the program on the Fedora Core 4 machines.
>
> I just wondered if this is a known issue or whether anyone else has any 
> experience of such problems?  Is there something I need to do to be able 
> to use the later zlib version?
>
>
> Thanks,
>
> Jeff Clifford.
>
>
>
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel