I’ve worked for a while on my plugins, where one of them is impulse generator, and second one is FFT analyser. I always debug it in Logic Pro X or in Juce Plugin Host example. And I get no error. There are some pending performance issues, or some remote functions (buttons) which still don’t work as I wish, but nothing that I could suspect to cause errors. At all I don’t get any errors in debug mode or any memory leakage. And it always work fine.
But suddenly when I first time tried to use my plugins during real recording session, and as soon as I launched my plugin (released version, which I also tested earlier on empty Logic project) Logic Pro X just disappeared with error message “Logic has been closed unexpected” or something like that.
Next time I launched my plugin in the same Logic project there was no such error. It was only once. But you can imagine my pain when first time you test your plugin in real session, when your friends are watching.
How to find culprit of that accident (except me )? Is there anything special that you know it could cause such unexpected error?
Some time ago I had similar problem, and in those days it was some issue with number of inputs or outputs. Now I am not sure, but I think it’s not the case.
Don’t know how to deal with that.
For any help thanks in advance.
Did Logic give you a crash report when it crashed?
That should tell you what took it down, if it was your plugin and the stack trace if it was.
If you’ve stripped your symbols though, you’ll need to symbolicate with the
Hello Dave, thank you for your support.
There was probably some report, but I forgot to save it.
But what is interesting for me, what do you mean
atos? I tried to search in the google but found nothing about that. Did you mean that: atoi ?
atos is a command line tool for symbolicating stack traces on macOS.
You can see the manual by typing
man atos from Terminal or online here: https://www.unix.com/man-page/osx/1/atos/
Hello, thanks again.
Unfortunately (or fortunately before I share my plugin) similar error happened again, and that time I saved Logic crash report. But I don’t know how to draw conclusion from it.
In the report there is once mentioned my method which I know cause used it in my plugin. So I can try to debug it more precisely. But maybe there is any info in that report that tells at which part of my thread should I debug especially? I think it has something to do with Timer, but I am not sure. In the report it looks like that:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff5b073b86 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff5b129c50 pthread_kill + 285
2 libsystem_c.dylib 0x00007fff5afdd1c9 abort + 127
3 libsystem_malloc.dylib 0x00007fff5b0eb6e2 malloc_vreport + 545
4 libsystem_malloc.dylib 0x00007fff5b0ff86c malloc_zone_error + 184
5 libsystem_malloc.dylib 0x00007fff5b0e7e87 small_free_list_remove_ptr_no_clear + 1195
6 libsystem_malloc.dylib 0x00007fff5b0e6fcf free_small + 685
7 com.pajczur.pajAUanalyser 0x0000000140c56f6b DrawingThread::pajSettings(int, float, float) + 5083
8 com.pajczur.pajAUanalyser 0x0000000140c4d539 PajAuanalyserAudioProcessorEditor::settingsTimerCallback() + 137
9 com.pajczur.pajAUanalyser 0x0000000140c91be0 juce::Timer::TimerThread::CallTimersMessage::messageCallback() + 352
10 com.pajczur.pajAUanalyser 0x0000000140c8f4cc juce::MessageQueue::deliverNextMessage() + 236
11 com.pajczur.pajAUanalyser 0x0000000140c8f38e juce::MessageQueue::runLoopSourceCallback(void*) + 14
12 com.apple.CoreFoundation 0x00007fff2de20129 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
13 com.apple.CoreFoundation 0x00007fff2de200cf __CFRunLoopDoSource0 + 108
14 com.apple.CoreFoundation 0x00007fff2de03fc8 __CFRunLoopDoSources0 + 283
15 com.apple.CoreFoundation 0x00007fff2de03517 __CFRunLoopRun + 1226
16 com.apple.CoreFoundation 0x00007fff2de02dfa CFRunLoopRunSpecific + 467
17 com.apple.HIToolbox 0x00007fff2d08e895 RunCurrentEventLoopInMode + 293
18 com.apple.HIToolbox 0x00007fff2d08e5cb ReceiveNextEventCommon + 618
19 com.apple.HIToolbox 0x00007fff2d08e348 _BlockUntilNextEventMatchingListInModeWithFilter + 64
20 com.apple.AppKit 0x00007fff2b34b95b _DPSNextEvent + 997
21 com.apple.AppKit 0x00007fff2b34a6fa -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362
22 com.apple.logic10 0x000000010a5d8add 0x108f5a000 + 23587549
23 com.apple.AppKit 0x00007fff2b34475d -[NSApplication run] + 699
24 com.apple.AppKit 0x00007fff2b333e97 NSApplicationMain + 780
25 com.apple.logic10 0x000000010997450d 0x108f5a000 + 10593549
26 libdyld.dylib 0x00007fff5af35085 start + 1
There is also other part of report where “crash” word is used:
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x00000001196fd5c0 rcx: 0x00007ffee6ca3f18 rdx: 0x0000000000000000
rdi: 0x0000000000000307 rsi: 0x0000000000000006 rbp: 0x00007ffee6ca3f50 rsp: 0x00007ffee6ca3f18
r8: 0x0000000000000000 r9: 0x00007ffee6ca3e70 r10: 0x0000000000000000 r11: 0x0000000000000206
r12: 0x0000000000000307 r13: 0x0000000115398000 r14: 0x0000000000000006 r15: 0x000000000000002d
rip: 0x00007fff5b073b86 rfl: 0x0000000000000206 cr2: 0x00007fff8cd42188
But I have no idea how to use that info. Could anyone help me?
I attache whole report here: logic_report.txt (121.4 KB)
For any help thanks in advance.
In that stack trace the last function in your code before crashing was
DrawingThread::pajSettings(int, float, float), so you’ll want to start investigating there
Also, try running with Asan on, it can save your life in things like this. Especially bugs that only happen in release builds: https://developer.apple.com/documentation/code_diagnostics/address_sanitizer/enabling_the_address_sanitizer