Obscure crash (AU plugin on OSX)

MacOSX and iOS
1

Hi guys,
some customers are reporting me that my plugin is crashing and I’m not able to replicate the issue at all. Tried on two different Macs and no crashes.
The last error log I received makes me think that it could be related to an error reading png files. Am I right?

Here’s an excerpt.

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fffaebcbd42 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fffaecb9457 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fffaeb31420 abort + 129
3   libPng.dylib                  	0x00007fff9b5f36de png_longjmp + 40
4   libPng.dylib                  	0x00007fff9b5f3391 _cg_png_error + 105
5   libPng.dylib                  	0x00007fff9b5e8530 _cg_png_read_row + 1111
6   com.apple.ImageIO.framework   	0x00007fff9b3a0a97 PNGReadPlugin::copyImageBlockSet(InfoRec*, CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 4479
7   com.apple.ImageIO.framework   	0x00007fff9b39d83a PNGReadPlugin::CopyImageBlockSetProc(void*, CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 146
8   com.apple.ImageIO.framework   	0x00007fff9b3a7d8b IIOImageProviderInfo::copyImageBlockSetWithOptions(CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 347
9   com.apple.ImageIO.framework   	0x00007fff9b3a613c IIOImageProviderInfo::CopyImageBlockSetWithOptions(void*, CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 352
10  com.apple.CoreGraphics        	0x00007fff997a2139 CGImageProviderCopyImageBlockSetWithOptions + 142
11  com.apple.CoreGraphics        	0x00007fff9990947e img_blocks_create + 302
12  com.apple.CoreGraphics        	0x00007fff999125ee img_data_lock + 2860
13  com.apple.CoreGraphics        	0x00007fff99911a84 CGSImageDataLock + 247
14  com.apple.CoreGraphics        	0x00007fff997a49fe ripc_AcquireImage + 991
15  com.apple.CoreGraphics        	0x00007fff997b30d2 ripc_DrawImage + 867
16  com.apple.CoreGraphics        	0x00007fff9982b34a CGContextDelegateDrawImage + 48
17  com.apple.CoreGraphics        	0x00007fff9991a767 CGContextDrawImageWithOptions + 539
18  com.apple.CoreGraphics        	0x00007fff9991aa18 CGContextDrawImage + 51

The plugin is built on OSX 10.12.3 with JUCE 3.2

Thanks!

2

Can’t really help with versions that aren’t the latest, I’m afraid. If you can reproduce a similar problem with the latest version, we’ll look into it.

3

I see. The problem is that I can’t reproduce the error too. What I’m asking is if I read the log correctly and there’s something wrong while reading the png files.

4

Yep, it does look like something weird going on in decompressing the png, but couldn’t really say much more without being able to debug it.

5

Thanks Jules

6

If you get errors, but they happen in places, where you didn’t write code yourself, there is always a fair chance, that you suffer from memory corruption (e.g. writing on pointers outside the buffer).
I haven’t tried it yet, but there is a tool on Mac to find such things, called Adress Sanitizer.
It’s worth a try…

1 Like
7

Unfortunately I’m not getting any errors. the plugin works flawlessly on two different Macs, but I got a bunch of clients that are reporting me the same issue with similar logs.

8

Do you have the dSYMs for the build that your customer is using?

9

no, but I can manage to recompile and send the customer a build where I have the dSYM for. In this way I shoud see a symbolicated crash report, right?

10

Well, you can avoid giving the customer the dSYM and still symbolicate the crash using the atos command line tool from the load address (0x13cbb5000 in the above) and the address of your calls (e.g., 0x000000013cc5aa68 for line 19 in that call stack)

1 Like
11

Thank you very much Martin, that’s a life saver.
The crash seems to happen when I try to load one of my knobs. I have a class that I’ve always used and never had any issues before. The process is:

Image myKnob = ImageCache::getFromMemory (BinaryData::knob_png, BinaryData::knob_pngSize);
addAndMakeVisible(mySlider = new AnimatedKnob(myKnob, 128, false, *processor.myParam)); //128 is the number of frames in the png file

Looking at the crash report with atos, it aborts after trying to load the png from memory. I’m now checking if anything is wrong with that png file, but it’s strange that only a small portion of my customers are experiencing this issue.

12

A shot in the dark here, but could it be that running the plug-in in 32-bit / 64-bit mode makes any difference?
I assume that you are trying to reproduce it in a 64-bit environment, and also the addresses in the crash report seem 64-bits, but who knows…