Debugging a plugin crash report

I just received a crash report from a user and I’m trying to figure out if the problem is with my plugin or the host. I can’t repeat the crash at all and no one else has reported anything even remotely similar. (this is with a VST plugin on a Mac)

Here’s the relevant part of the crash report:

Thread 0 Crashed:: Juce Message Thread  Dispatch queue:
0   libsystem_kernel.dylib        	0x00007fffc60e5dd6 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fffc61d1787 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fffc604b420 abort + 129
3   libc++abi.dylib               	0x00007fffc4ba885a abort_message + 266
4   libc++abi.dylib               	0x00007fffc4bcdc4f default_terminate_handler() + 267
5   libobjc.A.dylib               	0x00007fffc56d7b8e _objc_terminate() + 103
6   libc++abi.dylib               	0x00007fffc4bcad69 std::__terminate(void (*)()) + 8
7   libc++abi.dylib               	0x00007fffc4bcade3 std::terminate() + 51
8   com.mycompany.myplugin          0x000000018bd3bcb2 0x18bd36000 + 23730
9   com.mycompany.myplugin          0x000000018bd3b52a 0x18bd36000 + 21802
10  com.mycompany.myplugin          0x000000018bd39fcf 0x18bd36000 + 16335
11  com.mycompany.myplugin          0x000000018bd37eb6 0x18bd36000 + 7862
12       	    0x00000001002a213d 0x10008a000 + 2195773
13        	0x00000001002abc0b 0x10008a000 + 2235403

When I symbolicate the crash, stack lines 8-11 translate to:

8 JuceVSTWrapper::createEditorComp() (juce_VST_Wrapper.cpp:1064)
9 JuceVSTWrapper::SpeakerMappings::vstArrangementTypeToChannelSet(VstSpeakerConfiguration const&) (juce_VST_Wrapper.cpp:846)
10 JuceVSTWrapper::dispatcher(int, JuceVSTWrapper::VstOpCodeArguments)(juce_VST_Wrapper.cpp:1861)
11 pluginEntryPoint(long long (*)(VstEffectInterface*, int, int, long long, void*, float))(juce_AudioProcessor.cpp:244)

So it looks like it’s crashing somewhere in createEditorComp() but I don’t know how to proceed from there. I’m wondering if the host is passing something odd to the pluginEntryPoint().


The + xxxx value is the distance past the entry point to the function where the crash occured. You can dig in with the disassembler to find out exactly what instruction caused the crash. Though is function 9 supposed to call function 8? Looks odd to me … and those + xxx values seem mighty large at first glance. I wonder if you’ve got stack corruption and this is stack trace is slightly bogus?