Could not get to attach to the AUHostingServiceXPC either.
What I did was sprinkling a few debug messages here and there to find the culprit,
not as easy as stepping in a debugger, but it worked.
what was it? might be useful to post here as it might help others…
It was something to do with processor / editor separation, I can’t remember exactly sorry.
It wasn’t a Juce plugin, but what I did was to replace direct accesses between processor/editor with Audio Unit custom properties (using POD + memcpy).
I’m not sure how’s that implemented in Juce though.
1 Like
Hey guys,
I have a new Macbook Pro Silicon, with Big Sur 11.2.1, XCode 12.4, JUCE 6.0.5 and Logic Pro 10.6.1… and everything is perfectly fine. I can run plugins in debug mode, copied in the user’s Library folder, and in release you need to build against the “Any Mac” destination to make it Universal Binary 2.
I suggest you to build in Debug, then open logic, run the Plugin Manager and manually retry the validation if the failed plugin. This should give you more information about what’s causing your issue.
My 2 cents
2 Likes
thx, but it’s not a validation issue, all plugins validate fine. it’s when the plugin is loaded by AUHostingServiceXPC that there’s an issue sometimes.
Just started on my M1 journey.
Did anyone figure out how to attach a debugger to AUHostingServiceXPC? Crash reports are getting me so far, but being able to actually debug would make this a whole lot easier.
not me so far, not been on this recently, though will be back on it in a couple of weeks.
If you disable SIP then you should be able to attach the debugger to AUHostingServiceXPC_arrow (I had to attach to the ‘_arrow’ version). Works here.
I posted to the Apple dev forum about this and received a response from Apple support:
https://developer.apple.com/forums/thread/674706
Important: Don’t leave SIP disabled.
Also, I’ve been able to debug the JUCE AudioPluginHost without fooling around with SIP.
sucks that there’s no way to do this without disabling SIP.
Thanks. My problems seem to be specific to Logic though, so debugging in other hosts doesn’t tell me much.
Yeah, there’s issues with the new sandboxing system that just cannot be reproduced in audio plugin host
there probably is a way, add the com.apple.security.cs.allow-dyld-environment-variables entitlement to the app you want to debug, inject a library that intercepts the AU XPC service loading call, and make it load an alternative XPC service which has the debugging entitlements…
ok, so I’ve given this a go.
disabling SIP worked and allowed me to attach to the _arrow process and set a breakpoint in the plugin init code which got called !
unfortunately there is no DBG logging in the window and if I let the plugin run, it just ends without stopping (i.e. hitting a crash point) and Logic then displays the same “unstable” dialog.
so progress, but still no idea what is causing the crash.
So I managed to trace through and the as soon as I step over the return in this function then Logic pops up the dialog:
Not really sure what to do with this information… 
Interestingly,
OSStatus ComponentBase::AP_Close( void *self)
still gets called so it looks like the plugin is still alive and has not crashed, it’s just that the hosting process has decided it’s not ok for some reason…?
still can’t believe there’s no info from Apple on this process and it’s just a black box.
Not sure what type of plugins people are having problem with here, but a basic midi fx plugin will not start:
DEAR FRIENDS, IVE FOUND THE SOLUTION!!!
You should run Logic under rosetta until your 3rd party plugins are ported. This will probably fix your problems.
Find Logic in your /Applications folder, right click, select Get Info, then tick the “Open using Rosetta” checkbox.
LOVe YAll Vincent <3
1 Like
That doesn’t help I don’t think. These are our plugins which have been ported…