AUHostingServiceXPC_arrow crashing consistently on Release AU builds using latest Develop branch

Huge thanks to @reuk and @t0m for quick response on a Sunday!

I have published my minimal test plug-in code to GitHub. An Audio Unit built from this code can be loaded into Logic Pro without crashing, but unfortunately, it seems the audioWorkgroupContextChanged function does not actually get called.

If we can get past this hurdle, I’ll start a new forum topic for further issues. I wanted to stick with this one for now, mostly to put my thanks to the JUCE guys in context.

Hi @getdunne.

I’ve just run your code. It looks like you forgot to attach the PluginEditor::ChangeListener to your PluginProcessor. It started working once I did this :slight_smile:

@oli1 Oops, you’re right! Fixing this and making a couple of additional changes has proved highly instructive:

  1. Just adding the missing addChangeListener() call isn’t enough (of course), because Logic Pro X calls the processor’s audioWorkgroupContextChanged() function before creating the editor. I had to add the line changeListenerCallback(nullptr) at the end of the editor constructor to ensure the display message got updated.
  2. To test the actual ChangeListener callback mechanism, I tried changing the current audio output device in Logic Pro X’s settings. My plug-in’s editor closed, and when I re-opened it, I again saw that exactly one audioWorkgroupContextChanged() call had occurred.
  3. I suspected that Logic had quietly re-instantiated the plug-in, rather than making a second call to audioWorkgroupContextChanged() on the original instance, so I added code (see the GitHub repo) to detect this. Sure enough, that’s exactly what happened.

Embarrassed though I may be for forgetting the ChangeListener connection, I’m delighted that

  • I have confirmation that Logic is indeed calling audioWorkgroupContextChanged() on my Audio-Unit plug-ins.
  • I have learned something new about how Logic actually handles audio-device changes, and
  • I now have a working AU test plug-in which I can use to test other plug-in hosting scenarios.

Thanks to your timely help and a bit more digging, this hurdle is behind us. I’ll start a new topic to address other concerns.

I’m glad it’s working for you. Yes, Logic does seem to do some odd things with plugins, debugging it is quite a pain!

I think you forgot to add #if JUCE_AUDIOWORKGROUP_TYPES_AVAILABLE in commit [2882cdbc8]

Something new has come up. If I put two instances of my MTPlugin test AU plug-in on separate tracks in Logic Pro X, then click back and forth between the tracks to enable one and then the other, AUHostingServiceXPC_arrow will eventually crash with a different error:

Thread 6 Crashed:: AUOOPRenderingServer-11887798
0 libobjc.A.dylib 0x186a77f00 objc_retain + 16
1 caulk 0x190461c3c caulk::mach::details::retain_os_object(void*) + 20
2 AudioToolboxCore 0x188c15130 void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, AUOOPRenderingServer::AUOOPRenderingServer(int, int, int, std::__1::vector<AudioStreamBasicDescription, std::__1::allocator> const&, unsigned int, unsigned int, applesauce::xpc::dict const&, std::__1::shared_ptrauoop::WorkgroupMirror)::$_0, std::__1::tuple<>>>(void*) + 1152
3 libsystem_pthread.dylib 0x186e13fa8 _pthread_start + 148
4 libsystem_pthread.dylib 0x186e0eda0 thread_start + 8

The crashing seems to be triggered only when some MIDI has been sent to one of the tracks. I’m scratching my head about this. The plug-in code does virtually nothing, so I’m thinking it might be something in the JUCE AU client code??

1 Like

@getdunne thanks for reporting. I’ve been looking into this today. I managed to reproduce the issue both with your example plugin and with the MultiOutSynthPlugin Demo. After performing a bisect I was able to confirm the issue started when the Audio Workgroup commit was added. I’ve tracked down the issue but it’s not completely clear to me yet what the right solution is so I’ll likely pick this up again next week. It looks like this is only impacting software instruments (although I haven’t tested all the different AU plugin types).

2 Likes

@anthony-nicholls Thank you. Your responsiveness on these issues is hugely appreciated!

Well @getdunne I got to the bottom of the issue you shared but in the process came across another issue that was intermittent and much harder to track down! I think I’ve got to the bottom of both issues and I have something up for review. I’ll try to keep you posted but hopefully we can have something merged soon.

2 Likes

@getdunne just an update on this. There were some other use cases to consider that it looks like I’ve broken. I’m hoping we can get something in early next week. Sorry for the wait.

1 Like

Just using the latest tip and logic, and getting these errors when starting and stopping playback in logic with my AU

looks related

``
Thread 10 Crashed:: AUOOPRenderingServer-101257482
0 libobjc.A.dylib 0x1a95f3a54 objc_retain + 16
1 caulk 0x1b2fddc3c caulk::mach::details::retain_os_object(void*) + 20
2 AudioToolboxCore 0x1ab791130 void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, AUOOPRenderingServer::AUOOPRenderingServer(int, int, int, std::__1::vector<AudioStreamBasicDescription, std::__1::allocator> const&, unsigned int, unsigned int, applesauce::xpc::dict const&, std::__1::shared_ptrauoop::WorkgroupMirror)::$_0, std::__1::tuple<>>>(void*) + 1152
3 libsystem_pthread.dylib 0x1a998ffa8 _pthread_start + 148
4 libsystem_pthread.dylib 0x1a998ada0 thread_start + 8

Yep that’s the one. I hope to get something in early next week. For now you might be best off building from this commit, just before the issue was introduced.

Sorry for the inconvenience.

Any news on this ?
I have report of crashes in
Thread 56 Crashed:: com.apple.audio.IOThread.client
0 libdispatch.dylib 0x18cd32e24 _os_object_retain + 64
1 AudioToolboxCore 0x18eb695b0 RenderContextChangeGenerator::checkChange() + 28
2 AudioToolboxCore 0x18ed522e8 AudioUnitRender + 692

Thanks !

That is the same crash again, please bear with us, I promise a fix is coming! 10 years of development and I’m still no better (maybe even worse) at predicting when code might actually be merged :laughing:

We’re running into this with an upcoming release and it’s quite urgent… please update when a fix or a workaround exists.

This will be my number one priority from tomorrow (Monday).

2 Likes

please update when a fix or a workaround exists.

IIUC a workaround already exists:

for now as workaround I’ve set JUCE_AUDIOWORKGROUP_TYPES_AVAILABLE to 0

2 Likes

Thank you! This saved the day!

1 Like

Thanks all for being so patient. This should now be fixed on the latest tip of develop.

4 Likes