My Audio Unit plugin is crashing in Logic when not using Rosetta. I managed to get info on how to debug using Xcode, and it breaks with an access violation (code 2) after some huge number of recursive calls, when trying to show the plugin window. Here is a screen shot of the bottom of the stack. The rest goes on with the same exact set of calls, until it crashes.
Anyone know what is going on, or how to fix it? (We get the crash on both OS 11.6 and 12(.2? I forget exactly), but I’m debugging on 11.6 with Xcode 13.2.1, using a deployment target of 10.14.
The same plugin works fine in Studio One, and as AAX or VST3 in various hosts.
We have enabled ARA (via the JUCE_ARA SDK), but not completed work on that. Could the editor component have a clashing ID between the two plugin types (ARA and non-ARA)? There is only one plugin, but it shows up as two different plugins in Logic. Both ARA and non-ARA open fine in Studio One, though. Just trying to pinpoint what is specific to this scenario.
The problem appears to be that we recently added code to show an alert if some factory presets were not present, and that code uses the standard modal alert, which caused this to happen somehow. Adding the preset(s) to their expected location prevented that popup from showing, and the plugin now instantiates fine.
We’ll need to change that code to not use a modal alert, though. Can’t have this happen in the field!
We have received several similar stacktrace reports from users via our crash reporting tool on apps we have developed.
However, we do not know what steps to take to cause these crashes.
You mention ‘standard modal alert’, what exactly is the screen?
Our app is built with JUCE_MODAL_LOOPS_PERMITTED == 0, so there should be no modal dialog.
So I am confused as to what the ‘standard modal alert’ is.
It would be very helpful if you could tell me.
Any window that must attach itself to a parent window in order to be part of the event loop of the main GUI thread, now needs to be re-evaluated in the context of AUv3 usage - as AU plugins now no longer inherit from their parent window, but are separately sandbox’ed threads.
This problem will manifest with popup menus as well as alert dialogs which attempt to refer to a parent window in their context …
The solution is to remove any sub-windows from your app - popup menu’s, modal dialogs, etc. and replace them with components that are attached to your main plugins’ window.
AUV2 is where the requirement for a separate process/thread from the instantiating application comes from. I had the same situation as you - I had a popup menu that never worked when I built our plugins as AUV2, and my solution was to simply replace the popup menu (factually a child window that has to be bound to a parent - not possible in the AUV2 sandbox requirement now) with a radio/combo box, which worked out fine for our UI case.
There might be a way to pass the original (instantiating applications) window context to the popup menu, but I didn’t find it, and I also didn’t like how much of a ‘smell’ any hacky solutions were - for me it was simply more effective to re-do the UI to avoid sub-/child- windows. But it will of course be quite interesting to see if there is another way around this that is future-proof as well as conformant to the new process sandbox’ing requirements that come with AUV2…
I don’t know, why this thread was marked as resolved. Avoiding any kind of desktop windows might be a workaround in some cases, but it is not a solution for the issue itself (and not an option for me).
In Logic/M1, I had also seen the following error message frequently:
An Audio Unit plug-in reported a problem which might cause the system
to become unstable.
When debugging that issue, I got the same endless loop of becomeKeyWindow / grabFocus calls that were mentioned above in the first entry of this thread.
I created a simple test plugin using the latest JUCE version from the master branch.
The plugin has a button that will open an AlertWindow using showOkCancelBox().
I could reproduce that issue like this:
Click the button to open the AlertWindow
Click into a different window (e.g. a Finder window)
Click into the plugin or the AlertWindow again
Then the error occurs.
If I do it like this:
Click the button to open the AlertWindow
Click into a different window (e.g. a Finder window)
Click into the Logic window
Click into the plugin or the AlertWindow
the problem does not occur.
Does someone from the JUCE team have an idea if this is something that could be fixed in JUCE? Or could this be a bug in Logic’s AUHostingServiceXPC_arrow bridge?
As I said, I resolved it initially by not allowing the condition to happen where the alert window was shown. But in case the condition does happen (i.e., someone deletes the files that were there previously and still expected to be there) we now use a Component and show/hide it in front of the rest of the plugin instead of using an AlertWindow.
Avoiding any kind of desktop windows might be a workaround in some cases, but it is not a solution for the issue itself (and not an option for me).
I think for Standalone Apps, you are right - but for Plugins, this is not so black and white any more. With AuV3, plugins are very limited with regards to their sandbox access, and the references required to instantiate child windows as popups of the parent are simply not there any more. The sandbox is here, we have to learn to deal with it.
So, be careful with this. You may find yourself having to administer multiple code paths - one direction for Plugins on Windows/Linux and another set for MacOS/iOS.
It may be more effective to just re-do your UI to not require popup/child windows from the get-go. It certainly seems to be the future for AuV3 plugins, anyway …
