Jeepers. You’d better report it to the relevant authorities!
I’m actually just updating to 1.6.1 now anyway, since the version in the juce tree was several years old. If you let me know a safe patch, I can add that too while I’m doing it.
[quote=“jules”]Jeepers. You’d better report it to the relevant authorities!
I’m actually just updating to 1.6.1 now anyway, since the version in the juce tree was several years old. If you let me know a safe patch, I can add that too while I’m doing it.[/quote]
I suppose we should find out if 1.6.1 fixes the problem. If you’re about to put it in the tip code, I certainly have the stress test (otherwise known as my plugin) for it. As far as a patch goes, it should be simple, just changing that parameter in png_read_destroy to a ptr_ptr. I’m not sure how many callers there are for that function (I think there are a few), so the calls would have to be modified.
Ok, will check it in later today. Let me know what happens.
Well…
I just grabbed the new code. It doesn’t crash. It also doesn’t load the pngs. Now I’ve got to see whether this is a dumb one or an easy one.
Sit tight. I didn’t do a full clean ahead of the build.
Well, I tested the loader here, and it does work for the pngs I tried. Try opening the introjucer and viewing some png files with it.
There’s a problem with color profiles. Some of my pngs use the Pro Photo profile and the translater throws an exception when it hits them (the old version worked). It looks like sRGB is all it accepts and it may be kind of choosy about that. I’ll hop into Photoshop and do some translating to see what I can find. That’s why your pngs are loading–I’m sure you have a different color profile. What the translator should do is simply to default to sRGB or ignore the profile completely.
Windows itself knows how to handle Pro Photo (even if that’s just to ignore the profile). But don’t get me started on Windows color management.
There are a bunch of option flags that need to be set to enable various things - perhaps I’ve missed one out. If you can send me a png that doesn’t work, I could have a look.
Sure. I’ll send you something offline in a bit. I’m just getting ready to test the pngs converted to sRGB.
Well so far, so good. The latest tweak appears to have done the trick. Pngs that weren’t loading before are now loading in circumstances that were previously guaranteed to crash. It will probably take another day or two before I fully let down my guard, but I have reason to feel encouraged for the first time in weeks.
Thanks!
Just to make sure I’m getting this right:
[list]
[] Before 2013.4.3, JUCE used a faulty libpng loading png on Windows (and Linux?) which occasionally crashes.[/]
[] The newest libpng still has this bug. But Mikey has a patch for it.[/]
[] JUCE now has the newest libpng with the fix applied to it. (btw is someone contacting libpng?)[/]
[] Therefore, everyone should update to the latest JUCE to avoid rare crashes in Windows.[/][/list]
Is that right?
Cheers, Yair
Yes, that’s the upshot. Except that I think Mikey said the problem is already fixed in the latest libpng, so no need for patching or reporting it.
[quote=“yairadix”]Just to make sure I’m getting this right:
[list]
[] Before 2013.4.3, JUCE used a faulty libpng loading png on Windows (and Linux?) which occasionally crashes.[/]
[] The newest libpng still has this bug. But Mikey has a patch for it.[/]
[] JUCE now has the newest libpng with the fix applied to it. (btw is someone contacting libpng?)[/]
[] Therefore, everyone should update to the latest JUCE to avoid rare crashes in Windows.[/][/list]
Is that right?
Cheers, Yair[/quote]
Almost. Once the bug was understood, it wasn’t too difficult to come up with a patch. But I never implemented it because Jules updated libpng. It appears that the problem was discovered somewhere along the way, since the newer version of libpng works cleanly (so far at least). I do think that users of older versions of Juce will either need to update or will need to work out the patch for themselves (I think it’s pretty clear in the half-dozen posts before this one).
Because this bug depended so much on the fragmentation status of the heap, it’s one of those things that could appear irregularly–often never. It wouldn’t surprise me at all to see it as the source of some mystery one-offs crashes. I suppose I was lucky (doesn’t feel exactly like luck) to have discovered a way to drive it consistently. I’m more than a little glad to see it gone.