Png loading problem


#1

Using both version 1.46 and 1.5 I am running into an occasional crash while loading images using imageFileFormat::loadFrom() . It looks like there is a corruption problem corrupting memory in either the heap or statictly allocated memory. It happens only in a release build if OPT:/NOREF is set. This project setting in the linker tells it to not remove unreferenced data/code. It appears that this setting may just move the problem somewhere else such that the symptom does not appear. I would expect it to be worse when I build with OPT:/REF but it seems to work fine.

I have a simple project that loads a single png multiple times and it seems to crash after a different number of times depending on the day, but it always crashes. I can provide that project for debugging if it would help.


#2

I do lots of png image loading in my application and have had no problem with it. I would like to have your project for debugging.


#3

I suppose there could be a bug in the pnglib itself that’s having a problem with the particular file you’re using, but it seems odd - I use pngs all the time and have never had any problems.


#4

So I think the problem is visual studio, it’s either a bug or a user error but here are the details.

JUCE is a separate project of course and during a release build is built with full optimizations with link time code generation (LTCG) turned on. That means that some intermediate language code is left in the library so that the optimizer can optimize across module and .obj boundaries. I had a bug that only showed up in release mode so in my project I turned optimizations off. That apparently changed the default behavior of the OPT:REF option in the linker (optimizations->references) That field tells the linker to remove un-referenced code and data. The default behavior under a release build is to remove un-referenced code and data but if you turn optimizations off, it leaves that stuff in.

Having the JUCE project with LTCG on, and my project linking to it with OPT:NOREF set to leave un-referenced data/code in place creates a compatibility issue and I believe that the linker hooks things up incorrectly. Turning either LTCG off in JUCE or setting OPT:REF to remove un-referenced code solves the problem.

I could provide the project if you want… but I’m guessing you probably have better things to do.


#5

Ok, that does just sound like a compiler bug of some kind… Would be very hard to know where to begin in debugging it!