[Zlib-devel] HEADS UP: Apparent bad compilation under (just released) GCC 4.5.0
cosmin at cs.toronto.edu
Tue May 4 22:12:45 EDT 2010
Just an idea: could it be because the compiler optimizer became
aggressive enough to punish more of the ANSI aliasing violations?
Have you tried gcc with -fno-strict-aliasing?
2010/5/4 Török Edwin <edwintorok at gmail.com>:
> On 05/04/2010 08:47 PM, Jesus Cea wrote:
>> Now I have stranges crashes when using zlib 1.2.5, python and psyco (a
>> kind of JIT for python). I have a crash everytime I do an import of any
>> zipped library. 100% reproductible.
>> The problem is a memory corruption. Trying under GDB, the stack is very
>> The problem doesn't exist if I disable compiler optimizations when
>> compiling zlib.
>> After days messing with GDB with little luck, and knowing that the
>> problem seems to be related to optimization, I determine that the issue
>> is in "inftrees.c". If I compile everything optimized EXCEPT this
>> particular file, the crash vanishes.
> Which optimization level breaks it? Does it work with -O2? -O1?
> You can try to find out which individual optimization flag breaks it, by
> decomposing -O2 into individual optimization flags, and using a binary
> search to find out which flag is the culprit.
> If this happens at -O3 only, my usual suspect is -ftree-vectorize.
> For example you can decompose -O3 into individual flags by running this
> gcc-4.5 -O3 -Q --help=optimizers|grep enabled|cut -f1 -d\[|xargs echo
>> I compile zlib 1.2.3 and it crashes too!. zlib 1.2.3 is the version
>> currently running in my system, and it works... compiled with old
>> compiler. Compiling with GCC 4.5.0, it crashes.
>> I confirm this compiling zlib 1.2.5 under GCC 4.4.3, using other
>> machine. This version works correctly.
>> So, GCC 4.5.0 seems to be doing something wrong.
>> The only other option is that psyco is messing things. Could be
>> possible, since it generates x86 code directly (like a jit), so maybe it
>> is messing the environment. I am using version 1.6, released in 2007, I
>> think. Stable since.
> Does the bug occur if you try to compress/uncompress the file using
> Or can you find another way to reproduce the crash with python only
> (without psyco)?
>> I am still trying to determine the exact scope. But even if the fault is
>> not in zlib, I think it is useful you are aware of this particular
>> issue, just in case you start getting other negative feedback, now that
>> GCC 4.5.0 is out (two weeks ago).
> Can you take a stacktrace, or disassemble the code around the crash (if
> the stacktrace doesn't show useful line numbers)?
>> If you have any suggestion of how to debug this, please, let me know. I
>> have experience with ASM, but not under x86 (could try).
>> I am under Solaris 10, x86, compiling zlib as 32 bits.
> I was going to suggest running under valgrind, but I doubt valgrind
> supports Solaris.
>> If you think this messsage is inadecuate for zlib-devel, let me know.
> I don't know, gcc-help at gcc.gnu.org would be a good place to seek help on
> this too. I am not subscribed to that ML however.
> Best regards,
> Zlib-devel mailing list
> Zlib-devel at madler.net
More information about the Zlib-devel