AUHostingServiceXPC_arrow crashing consistently on Release AU builds using latest Develop branch

1

I have been trying to test the latest MacOS AudioWorkgroup support in JUCE 7.0.7 develop. Debug builds are fine, stand-alone app and non-AU plug-in builds are fine. Release AU builds are fine when I run Logic Pro X under Rosetta. Attempting to load a Release AU in Logic Pro X running natively yields the useless/condescending/smarmy error pop-up “An Audio Unit plug-in reported a problem which might cause the system to become unstable. Please quit and restart Logic Pro.” Within the Console app I’m able to see numerous AUHostingServiceXPC_arrow crash reports, all of which indicate a EXC_BAD_ACCESS (SIGSEGV) exception with KERN_INVALID_ADDRESS at 0x0000000000000000. The crash occurs in the main thread (Thread 0), and the stack trace always looks something like this:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_blocks.dylib 0x182906bb4 _Block_copy + 180
1 AudioToolboxCore 0x1848e350c RenderContextChangeGenerator& std::__1::optional::emplace[abi:v15006]<void (AudioUnitRenderContext const*) block_pointer __strong&, void>(void (AudioUnitRenderContext const*) block_pointer __strong&) + 60
2 AudioToolboxCore 0x1848e34a4 APComponentInstance::postOpen() + 120
3 AudioToolboxCore 0x1848e3068 APComponent::newInstance(unsigned int, bool, void (OpaqueAudioComponentInstance*, int) block_pointer) + 2576
4 AudioToolboxCore 0x1849bdd48 -[AUAudioUnitV2Bridge initWithComponentDescription:options:error:] + 740
5 AudioToolboxCore 0x18495a83c +[AUAudioUnit instantiateWithComponentDescription:options:connectionProvider:completionHandler:] + 1612
…

When I say the stack trace always looks “something like” the above, what I mean is that execution always gets into APComponentInstance::postOpen(), but what’s above that seems to vary a bit, as though what happens depends on the contents of some data structure which is uninitialized.

After wasting hours trying changes to my own plug-in code, I decided to create a new “do-nothing” instrument (aumu) AU plug-in using the Projucer (which I also compiled using the latest JUCE 7.0.7 develop code), and it had exactly the same issue.

The only way I was able to stop this from happening was to comment out lines 589-593 of juce_audio_plugin_client_AU_1.mm like this:

           #if JUCE_AUDIOWORKGROUP_TYPES_AVAILABLE
            case kAudioUnitProperty_RenderContextObserver:
            {
                if (auto* ptr = (AURenderContextObserver*) outData)
                {

// ptr = ^(const AudioUnitRenderContext context)
// {
// if (juceFilter)
// juceFilter->audioWorkgroupContextChanged (makeRealAudioWorkgroup (context != nullptr ? context->workgroup : nullptr));
// };

                    return noErr;
                }
            }
           #endif

I realize this completely lobotomizes the new AudioWorkgroup handling code. I tried making finer-grain changes, e.g. inside makeRealAudioWorkgroup(), but it’s all above my pay-grade.

I’m using the latest Logic Pro X v10.7.9, the latest Xcode 14.3.1, on an M1 Mac Mini running the latest MacOS Ventura v13.5.2. I have made a local fork of JUCE 7.0.7, selected the develop branch, and made certain it is up-to-date by pulling in the most recent changes from upstream/develop.

2

Could you try out this patch and see whether it fixes the issue for you?

workgroups.patch (2.0 KB)

3

Forgive me; I’ve never used .patch files before. Based on something I found by googling around, I put the workgroups.patch file into the JUCE main folder, then opening a shell window there and entered

git apply --index workgroups.patch

But I just got an error message saying

error: modules/juce_audio_plugin_client/juce_audio_plugin_client_AU_1.mm: does not match index

So, I did my best to follow the diff code, and make the requisite changes manually, and IT SEEMS TO WORK! Logic can now load both my “do-nothing” plug-in, and my own plug-in, after recompiling with these changes.

4

My AU cause Logic Pro crash (v10.7.9) after JUCE commit [7d9cdd301] “Audio: Add AudioWorkgroup support”

com.apple.audio.IOThread.client (19): EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

Test with patch:
start from a new project → fixed
start from a saved project (with some other plugins loaded) → crash

for now as workaround I’ve set JUCE_AUDIOWORKGROUP_TYPES_AVAILABLE to 0

1 Like
5

A fix for the first problem is available here:

6

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.

7

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:

8

@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.

9

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!

10

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

11
12

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
13

@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
14

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

15

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
16

@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
17

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

18

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.

19

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 !

20

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: