When I close the freshly built AudioPluginHost in Debug mode by right-clicking on the icon in the dock (macOS), I get a SIGABRT message in Xcode. I’m not pressing Alt, so to my knowledge, it should not be a force quit. Every other way of quitting works fine.
I encountered this on an M2 Mac, macOS 15.0.1.
I hope I’m not spreading misinformation, but from what I found, right-clicking in the dock is supposed to be a normal way to quit an app.
Little Disclaimer: Because of my bad english i used ai to rework my text, for grammar and typos, but all info is still correct. Just in case it sounds to generic^^
I originally used the pre-built download from juce.com, but now I’ve downloaded and built the develop branch and I’m still getting the same error. Just like last time, the first quit works fine, but from the second build onwards, I get the error again.
One thing that might be related: the window appears scaled the same way it was when I last saved the AudioPluginHost layout — even though this is a fresh build. Is there maybe a save file somewhere on my OS that I can delete?
Sorry, I’m still a bit new to all this — I only started learning C++ and JUCE a couple of months ago.
Some background info: I was testing my plugin and noticed a SIGABRT. I kept commenting out more and more code, and eventually I found that even after removing the plugin from AudioPluginHost, I still got the same error when quitting. So I rebooted my Mac and rebuilt AudioPluginHost, without any plugin loaded, but the error persisted. I assumed that any potential memory mismanagement from my plugin shouldn’t be an issue after a reboot — but maybe I’m wrong.
Anyway, just thought I’d share that. Again, sorry for being a bit of a noob. ^^
I am not shure how and what this is, but after a google search and asking chatgpt i think its this, but please correct me if i’m wrong:
JUCE v8.0.8: Message Thread (1) Queue : com.apple.main-thread (serial)
#0 0x0000000185d5bb08 in kevent_id ()
#1 0x0000000106699180 in _dispatch_kq_poll ()
#2 0x00000001066985b4 in _dispatch_event_loop_poke ()
#3 0x000000018a6520f0 in __54-[NSWMWindowCoordinator performTransactionUsingBlock:]_block_invoke_2 ()
#4 0x0000000189cfd688 in ___lldb_unnamed_symbol163771 ()
#5 0x0000000189cfba7c in ___lldb_unnamed_symbol163726 ()
#6 0x0000000189cfbbd0 in ___lldb_unnamed_symbol163728 ()
#7 0x000000018a651f90 in __54-[NSWMWindowCoordinator performTransactionUsingBlock:]_block_invoke.8 ()
#8 0x0000000189ae2ef0 in NSCGSTransactionRunPreCommitActionsForOrder_ ()
#9 0x0000000189ae2c34 in NSCGSTransactionRunPreCommitActions_ ()
#10 0x000000018a6594f8 in __39+[_NSCGSTransaction currentTransaction]_block_invoke.26 ()
#11 0x000000018e8aef00 in CA::Transaction::run_commit_handlers ()
#12 0x000000018ea5afc4 in CA::Context::commit_transaction ()
#13 0x000000018e8addb0 in CA::Transaction::commit ()
#14 0x000000018ea8b60c in CA::Transaction::flush_as_runloop_observer ()
#15 0x0000000185e817a8 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#16 0x0000000185e81694 in __CFRunLoopDoObservers ()
#17 0x0000000185e80380 in CFRunLoopRunSpecific ()
#18 0x00000001912b90cc in RunCurrentEventLoopInMode ()
#19 0x00000001912bed1c in ReceiveNextEventCommon ()
#20 0x00000001912bf020 in _BlockUntilNextEventMatchingListInModeWithFilter ()
#21 0x00000001899c4a70 in _DPSNextEvent ()
#22 0x000000018a2ea7b8 in -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#23 0x00000001899b7b7c in -[NSApplication run] ()
#24 0x0000000103374084 in juce::MessageManager::runDispatchLoop at /Users/x/Downloads/JUCE-develop/modules/juce_events/native/juce_MessageManager_mac.mm:347
#25 0x0000000103373f58 in juce::JUCEApplicationBase::main at /Users/x/Downloads/JUCE-develop/modules/juce_events/messages/juce_ApplicationBase.cpp:277
#26 0x0000000103373d84 in juce::JUCEApplicationBase::main at /Users/x/Downloads/JUCE-develop/modules/juce_events/messages/juce_ApplicationBase.cpp:255
#27 0x0000000102d6a618 in main at /Users/x/Downloads/JUCE-develop/extras/AudioPluginHost/Source/HostStartup.cpp:391
#28 0x0000000185a18274 in start ()
the breakpoint/error message is at:
#else
[NSApp run]; //here
#endif
in runDispatchLoop()
I don’t noticed any differences but i also don’t know what to look out for.
Another sidenote: I noticed a Timer Thread is active. Is that normal with audioPluginHost? Because my plugin used a timer, i just ask because i don’t know whats relevant
Thanks, based on the stack trace you provided it looks like the crash is happening within a macOS component, rather than in the JUCE code, so it’s difficult to guess at what might be causing the problem.
I tested on macOS 15.5 and didn’t see this problem, but you said that you’re testing on macOS 15.0.1. Given that the crash is happening within an OS component, there’s a chance that this is an OS-level bug, and that updating will fix the issue. Please could you try updating your system and check whether the issue persists?
Normally you’d get a more detailed stack trace, but only if the problem is in the application that was built with address sanitizer enabled. Unfortunately, this crash looks like it’s happening in an OS component, so address sanitizer won’t be very helpful in this case after all.
Oh i was stupid sorry, the stack trace is from before i activated address sanitizer.
I’ve updated now and the error is still there.
I actually get a changed stack trace now with adress sanitizer enabled, sorry i did not see this at the time.
The stack trace is now:
JUCE v8.0.8: Message Thread (1) Queue : com.apple.main-thread (serial)
#0 0x0000000107aa9440 in __sanitizer_mz_malloc ()
#1 0x000000018874d12c in _malloc_zone_malloc_instrumented_or_legacy ()
#2 0x0000000188737c78 in _malloc_type_zone_malloc_outlined ()
#3 0x0000000191c0add0 in CA::Context::commit_transaction ()
#4 0x0000000191a573a8 in CA::Transaction::commit ()
#5 0x0000000191c3c9e4 in CA::Transaction::flush_as_runloop_observer ()
#6 0x0000000188a05098 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#7 0x0000000188a04f80 in __CFRunLoopDoObservers ()
#8 0x0000000188a03ca4 in CFRunLoopRunSpecific ()
#9 0x000000019449827c in RunCurrentEventLoopInMode ()
#10 0x000000019449b31c in ReceiveNextEventCommon ()
#11 0x0000000194626484 in _BlockUntilNextEventMatchingListInModeWithFilter ()
#12 0x000000018c92bab4 in _DPSNextEvent ()
#13 0x000000018d2ca5b0 in -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#14 0x000000018c91ec64 in -[NSApplication run] ()
#15 0x000000010197ad30 in juce::MessageManager::runDispatchLoop at /Users/x/Downloads/JUCE-develop/modules/juce_events/native/juce_MessageManager_mac.mm:347
#16 0x000000010197aa58 in juce::JUCEApplicationBase::main at /Users/x/Downloads/JUCE-develop/modules/juce_events/messages/juce_ApplicationBase.cpp:277
#17 0x000000010197a6ac in juce::JUCEApplicationBase::main at /Users/x/Downloads/JUCE-develop/modules/juce_events/messages/juce_ApplicationBase.cpp:255
#18 0x00000001005d7330 in main at /Users/x/Downloads/JUCE-develop/extras/AudioPluginHost/Source/HostStartup.cpp:391
#19 0x000000018857ab98 in start ()
ok i really should update my systems more frequently i also just noticed my xcode version is not new, so i update it quick and see if the error persists
to reproduce it you have to build the AudioPluginHost at least two times, because after rebooting the first build works fine, but from the second build the error persists
Thanks for the extra info. Unfortunately the crash still looks like it’s happening in an OS component, and I’m not able to reproduce similar behaviour here. I’ve tried running the app a few times, and also doing a clean build before re-running several times.
The crash could be related to displaying the application window, based on the stack trace.
Here I’m running an M4 Mac Mini with an external display. What model of M2 Mac are you using for testing? I wonder whether it’s a model with a variable-refresh-rate screen or some other display hardware that’s not present on my test machine.
Also, are you using a specific windowing mode, e.g. full-screen, or using Stage Manager, or something else?
I’m really guessing here - without being able to repro the issue locally we’re unlikely to be able to make progress on this issue. Could you take a screen recording showing how you trigger the crash? That way I can be sure I’m following the same steps.
Hey, sorry i did not see your answer and forgot about it. I use a 2023 Mac Mini with an external Display. And yes i screenrecorded building my current plugin and opening it in ADH as well as building the debug host itself. As you will see the bug did not occur when i clicked discard changes, so i did the same again but saved before with CMD+S. The Video was too big for the forum so i loaded it in my cloud, its available under: Proton Drive
Unfortunately I think this might be a bug in macOS. There’s some discussion on a similar issue here:
One participant in that thread mentions that they see the same issue in a completely blank project. I tested out the same thing, creating a new project with File → New → Project, then using the wizard to create a macOS app project. This blank app has the same problem, where right-clicking in the dock and quitting the app will sometimes raise SIGTERM. For me, the first few quits worked fine, and it wasn’t until the 4th or 5th try that I saw the SIGTERM.
I’d recommend quitting with cmd + q for the time being to avoid this issue. Hopefully a future Xcode/macOS update will resolve the problem.