png_error inside UIImagePNGRepresentation only on iOS 5.1+

Question

We are experiencing a strange crash where UIImagePNGRepresentation() is sometimes causing png_error calls. We have been unable to reproduce this error on any of our devices in house.

Here is an example of the stack trace from one of our HockeyApp crash logs:

Thread 0 Crashed:
0   libsystem_kernel.dylib         0x3167132c __pthread_kill + 8
1   libsystem_c.dylib              0x33d6729f abort + 94
2   ImageIO                        0x346c38bf png_error + 114
3   ImageIO                        0x346c2fe3 png_write_end + 46
4   ImageIO                        0x346bf069 writeOnePng + 2260
5   ImageIO                        0x346be78b _CGImagePluginWritePNG + 82
6   ImageIO                        0x346be6fd CGImageDestinationFinalize + 132
7   UIKit                          0x31346e23 UIImagePNGRepresentation + 274

We have only been seeing this crash logs on devices running iOS 5.1+ and above. We've actually been getting crashes from iOS 6 as well so this bug has not yet been fixed.

I wrote a test app that downloads over 16,000 of the possible images that our app can display and all of them were able to be downloaded and saved to disk with no problems. Some responses to this gist imply that this issue could be caused by corrupted images but seeing as how I downloaded over 16,000 images and never once had an issue I don't think this could be the case.

The latest hypothesis I am working on is that somehow the data being downloaded is corrupted and therefore a corrupted UIImage is being created. However all attempts to create a corrupted UIImage have failed. Apple seems to have created a robust constructor for UIImage such that anything that I pass in which is invalid results in a nil being returned from the constructor.

Has anyone else experienced anything like this from UIImagePNGRepresentation?

Answer 1

Have you tried testing with different network conditions? 3G or edge instead of just wifi? Try using the Network Link Conditioner to simulate these conditions of slow and lossy networks.

Answer 2

Are you making ANY UIKit calls from secondary threads? I've seen crashes where UIKit graphic calls on secondary threads work but the main thread crashes at some point later on. There are a few UIKit methods that are ok to use on secondary threads, but not many.

Answer 3

I've been wrestling with a similar local image corruption problem for a few months in my production app (using UIImageJPEGRepresentation() in my case), and in my case it had nothing to do with downloading the image - but the local storage and rendering.

In my case, the actual user effect of the error was that the image would only partially render; the remainder of the image simply appear gray and corrupt. I am storing and reading from the disk using Core Data (but Core Data was shockingly not my problem).

MY FIX:

I was formerly using this convenience method:

UIImage *image = [UIImage imageWithContentsOfFile:imagePath];

..but on the advice of some other related posts here , I switched to this combination of methods instead:

NSData *resultData = [NSData dataWithContentsOfFile:imagePath];
UIImage *image = [UIImage imageWithData:resultData];

..and it SEEMS to have solved my problem!

MY THEORY

I'm guessing that imageWithContentsOfFile: is, for some reason, worse at handling some non-atomical edge case conditions vs. the pure base NSData calls, and it is for some reason allowing a 'read' to begin before the previous 'write' has completed.

Hope this helps! Good luck.

Answer 4

If the call to UIImagePNGRepresentation is inside a loop, i saw a fix on another SO thread which suggests to add sleep(1.0); after the save.

Answer 5

We had this problem in an app running at scale. It was occurring over 1000 times a day. Using the logging capabilities in Crashlytics we were able to determine exactly which images were causing the crash.

There were about 25 images triggering the crash. We realized that every one of these images had been exported from Photoshop, whereas most of our images had been exported from Illustrator. The images rendered fine in every other program we tried, and we were never able to determine what was "wrong" with them. But we re-exported the images from Illustrator, and our incidence of this crash went to zero.

I realize this doesn't provide root cause but thought it might be helpful to someone else experiencing this issue.