[Bug]: JUCE 9.0.0 macOS: app deadlocks at launch inside CoreAudioIODevice::getInputLatencyInSamples (HALC_ProxyObject::HasProperty never returns) on a machine with many audio devices

[Vibehunter]

Detailed steps on how to reproduce the bug

Since JUCE 9.0.0's new macOS CoreAudio implementation, my JUCE standalone app deadlocks at launch, before its first window appears. The identical codebase built against JUCE 8.0.13 launches fine on the same machine, same day, same devices. Reproduced twice in a row, sampled both times (full sample outputs attached).

Setup

• macOS Ventura 13.7.8, Intel Mac Pro (2019, 7,1)
• JUCE 9.0.0 stable tag, zero source changes to my tree (compiles clean with zero warnings)
• The app is a standalone that hosts an AudioProcessor via AudioProcessorPlayer + AudioDeviceManager, opened in a split configuration: input and output are two different physical devices (a loopback driver in, a Thunderbolt interface out)
• The machine has about 18 CoreAudio devices present: Apogee Symphony I/O (Thunderbolt), three loopback virtual devices, six Pro Tools Audio Bridge devices, NDI Audio, BlackHole 2ch, ZoomAudioDevice, TV/display audio, and two user aggregate devices

Steps

1. Build the app (or plausibly any AudioDeviceManager client that queries latency at device setup) against 9.0.0
2. Launch it on a machine with a large CoreAudio device list, with input and output on different physical devices
3. During device setup, call AudioIODevice::getInputLatencyInSamples()

Result

The call never returns. The main thread sits forever in:

MyComponent (device setup)
  juce::CoreAudioClasses::CoreAudioIODevice::getInputLatencyInSamples()
    juce::AudioObject::getProperty<unsigned int>(...)
      AudioObjectHasProperty (CoreAudio)
        HALPlugIn::ObjectHasProperty
          HALC_ShellObject::HasProperty
            HALC_ProxyObject::HasProperty
              mach_msg -> mach_msg2_trap        (100% of samples, both runs)

The synchronous mach message to coreaudiod is never answered. No crash, no window, no dialog, 0.1 percent CPU, forever.

Second-order effect worth knowing

Force-killing the client while it is blocked in that proxy call left coreaudiod itself wedged: afterwards even a JUCE 8.0.13 client on the same machine blocked forever inside AudioDeviceStart (HALB_IOThread::StartAndWaitForState). Only killall coreaudiod recovered the system. So the failure compounds: the 9.0.0 hang invites a force quit, and the force quit degrades the whole audio stack.

What I ruled out

• Not my code: zero-change compile, my full DSP test suite passes 100 percent against 9.0.0, and pluginval strictness 10 passes on the 9.0.0-built VST3 and AU
• Not a one-off: reproduced on a second launch after a 12 second gap with a healthy coreaudiod
• Not a broken machine: 8.0.13 builds of the same app launch and run normally between the two 9.0.0 attempts

Suspicion

The new always-on private aggregate device path (aggregateDevicePrefix + pid) combined with a large device list. A dev machine with two devices likely never sees this; a pro-audio machine crowded with virtual devices and bridges hits it at launch.

Happy to run diagnostic builds or provide more samples.

What is the expected behaviour?

getInputLatencyInSamples() returns promptly (as it does on JUCE 8.0.13) and the app launches normally. On 8.0.13 the identical codebase, same machine, same 18-device list, launches and runs without issue.

Operating systems

macOS

What versions of the operating systems?

macOS Ventura 13.7.8 (22G921), Intel Mac Pro (2019, MacPro7,1)

Architectures

x86_64

Stacktrace

Run 1 (sample, 2416/2416 samples on the main thread):

2416 Thread DispatchQueue_1: com.apple.main-thread (serial)
+ 2416 start (in dyld)
+ 2416 juce::JUCEApplicationBase::main(int, char const**)
+ 2416 juce::JUCEApplicationBase::main()
+ 2416 juce::JUCEApplication::initialiseApp()
+ 2416 [our app] Application::initialise -> MainWindow -> component ctor
+ 2416 [our app] openAllDeviceChannels()
+ 2416 juce::CoreAudioClasses::CoreAudioIODevice::getInputLatencyInSamples()
+ 2416 juce::AudioObject::getProperty<unsigned int>(juce::PropertyAddress, juce::AudioObject::DataType) const
+ 2416 AudioObjectHasProperty (in CoreAudio)
+ 2416 HALPlugIn::ObjectHasProperty(HALObject const&, AudioObjectPropertyAddress const&) const
+ 2416 HAL_HardwarePlugIn_ObjectHasProperty(AudioHardwarePlugInInterface**, unsigned int, AudioObjectPropertyAddress const*)
+ 2416 HALC_ShellObject::HasProperty(unsigned int, AudioObjectPropertyAddress const&, bool&) const
+ 2416 HALC_ProxyObject::HasProperty(AudioObjectPropertyAddress const&, bool&) const
+ 2416 mach_msg (in libsystem_kernel.dylib)
+ 2416 mach_msg_overwrite
+ 2416 mach_msg2_internal
+ 2416 mach_msg2_trap

Run 2 (12 s later, fresh launch): identical deepest frames, 100% of samples in mach_msg2_trap under the same HALC_ProxyObject::HasProperty path.

Aftermath (JUCE 8.0.13 client on the same machine, AFTER force-killing the blocked 9.0.0 process, before killall coreaudiod):

juce::CoreAudioClasses::AudioIODeviceCombiner::start(juce::AudioIODeviceCallback*)
+ juce::CoreAudioClasses::CoreAudioInternal::start(juce::AudioIODeviceCallback*)
+ AudioDeviceStart (in CoreAudio)
+ HAL_HardwarePlugIn_DeviceStart
+ HALC_ProxyIOContext::_StartIO()
+ HALB_IOThread::StartAndWaitForState(unsigned int)
+ HALB_IOThread::_WaitForState(unsigned int)

Full sample outputs attached to the issue.

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

I have not tested against the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[Vibehunter]

The full sampled main-thread call graph from reproduction 1 (sample <pid> 3, all 2416 samples identical). Reproduction 2's graph is frame-for-frame identical. Every other thread in both samples is parked in ordinary waits (workqueue, JUCE Timer condvar), so this is the entire story:

Main thread call graph, run 1 (2416/2416 samples)

Call graph:
    2416 Thread_16001210   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2416 start  (in dyld) + 1896  [0x7ff80add6418]
    +   2416 juce::JUCEApplicationBase::main(int, char const**)  (in The Jackal) + 85  [0x10341d235]
    +     2416 juce::JUCEApplicationBase::main()  (in The Jackal) + 65  [0x10341d2c1]
    +       2416 juce::JUCEApplication::initialiseApp()  (in The Jackal) + 11  [0x10359e40b]
    +         2416 juce::JUCEApplicationBase::initialiseApp()  (in The Jackal) + 68  [0x10341d4b4]
    +           2416 rc::hub::JackalHubApplication::initialise(juce::String const&)  (in The Jackal) + 1139  [0x102faed13]
    +             2416 rc::hub::JackalHubApplication::MainWindow::MainWindow(juce::String const&)  (in The Jackal) + 108  [0x102fafc1c]
    +               2416 rc::hub::JackalHubComponent::JackalHubComponent()  (in The Jackal) + 3873  [0x102fb2ef1]
    +                 2416 rc::hub::JackalHubComponent::openAllDeviceChannels()  (in The Jackal) + 635  [0x102fb73db]
    +                   2416 juce::CoreAudioClasses::CoreAudioIODevice::getInputLatencyInSamples()  (in The Jackal) + 148  [0x103404b74]
    +                     2416 juce::AudioObject::getProperty<unsigned int>(juce::PropertyAddress, juce::AudioObject::DataType) const  (in The Jackal) + 65  [0x103400351]
    +                       2416 AudioObjectHasProperty  (in CoreAudio) + 120  [0x7ff80d0fa8b7]
    +                         2416 HALPlugIn::ObjectHasProperty(HALObject const&, AudioObjectPropertyAddress const&) const  (in CoreAudio) + 36  [0x7ff80d0f9c24]
    +                           2416 HAL_HardwarePlugIn_ObjectHasProperty(AudioHardwarePlugInInterface**, unsigned int, AudioObjectPropertyAddress const*)  (in CoreAudio) + 429  [0x7ff80d295dca]
    +                             2416 HALC_ShellObject::HasProperty(unsigned int, AudioObjectPropertyAddress const&, bool&) const  (in CoreAudio) + 692  [0x7ff80d3ab52e]
    +                               2416 HALC_ProxyObject::HasProperty(AudioObjectPropertyAddress const&, bool&) const  (in CoreAudio) + 147  [0x7ff80d484139]
    +                                 2416 mach_msg  (in libsystem_kernel.dylib) + 19  [0x7ff80b0f283a]
    +                                   2416 mach_msg_overwrite  (in libsystem_kernel.dylib) + 692  [0x7ff80b0f9584]
    +                                     2416 mach_msg2_internal  (in libsystem_kernel.dylib) + 78  [0x7ff80b1006cd]
    +                                       2416 mach_msg2_trap  (in libsystem_kernel.dylib) + 10  [0x7ff80b0f2552]

Additional environment detail in case it helps narrow it: the input device in the split configuration is our own AudioServerPlugIn loopback driver (16ch), the output is the Apogee Symphony I/O over Thunderbolt, and the machine also carries six Digidesign/Avid "Pro Tools Audio Bridge" devices, NDI Audio, BlackHole 2ch, ZoomAudioDevice, and two user-created aggregates. If a diagnostic build with extra logging in the new CoreAudio layer would help, I am happy to run it and report back.

[juce-push-bot]

This issue has been mentioned on The JUCE Forum. There might be relevant details there:

https://forum.juce.com/t/juce-9-0-0-macos-app-deadlocks-at-launch-inside-getinputlatencyinsamples-halc-proxyobject-hasproperty-never-returns-on-a-machine-with-many-audio-devices/69185/1

[Anthony-Nicholls]

@Vibehunter thanks for reporting I've posted a response on the forum https://forum.juce.com/t/juce-9-0-0-macos-app-deadlocks-at-launch-inside-getinputlatencyinsamples-halc-proxyobject-hasproperty-never-returns-on-a-machine-with-many-audio-devices/69185/2

[Vibehunter]

Update: ran the three diagnostics the JUCE team asked for on the forum thread. Machine: Ventura 13.7.8, Intel Mac Pro, 19 CoreAudio devices (Apogee Symphony I/O Mk II over Thunderbolt, three loopback drivers, six Pro Tools Audio Bridge devices, NDI, BlackHole, aggregates). Driver: current DEXT-based Apogee driver (com.apogeedigital.TBTDriver 1.0.20), with the older kext com.apogeedigital.kextSymphonyIO2T 0.8.7 still loaded alongside it. 8.0.13 launches fine in exactly this state.

1. Remove the Thunderbolt interface (Symphony I/O) and it launches every time. Reconnect it and it deadlocks at launch every time. The Thunderbolt device is the trigger.

2. Patch AudioObject::hasProperty to return true (never call AudioObjectHasProperty), logging off, and it launches with the interface connected. Main thread reaches -[NSApplication run]. Bypassing that one call gets past the deadlock.

3. JUCE_COREAUDIO_LOGGING_ENABLED=1: the log enumerates all 19 devices then bogs in a HALC_ProxyObject mach_msg that never returns. Note the logging build's AudioObject ctor calls AudioObjectShow() (logging-only, ~L498), which forces the first HAL checkout early, so it wedges in Apple's HALSystem::CheckOutInstance -> set_audio_processing_type_on_all_devices sweep rather than getInputLatencyInSamples. Same mechanism, different call site.

Consistent conclusion: the Thunderbolt device's HAL proxy stops answering synchronous property round-trips, and any main-thread property query at launch hangs the app. JUCE 9 builds a private aggregate from the selected in/out (_JucePrivateAggregateDevice_<pid>), with the Symphony as the output member, which is the member that hangs.

Hang stack (logging build):

CoreAudioIODeviceType::CoreAudioIODeviceType()
  AudioObjectShow -> HALSystem::CheckOutInstance()
    UpdateInputProcessingNotificationHandler()
      set_audio_processing_type_on_all_devices(...)
        HALObject::SetPropertyData / IsPropertySettable / HasProperty
          HALC_ProxyObject::* -> mach_msg2_trap   (never returns)

[Vibehunter]

Following up a week on, in case this one slipped.

Where it stands, briefly: 8.0.13 launches fine on this machine in exactly the state described. 9.0.0 deadlocks at launch every time the Thunderbolt interface is connected, and patching AudioObject::hasProperty to return true without calling AudioObjectHasProperty gets it past the deadlock. So a single synchronous HAL property query during launch is the whole problem, and the Symphony's HAL proxy is what stops answering it. Reproduces 100% of the time, and I still have the machine in that state.

One question would unblock me regardless of when a fix lands, and it may be a one-liner for you: is the private aggregate that 9.0.0 builds from the selected input and output (_JucePrivateAggregateDevice_<pid>) new in 9.0.0, and is there a supported way to avoid it, or to keep the launch path off synchronous property queries? I am pinned to 8.0.13 purely because of this and I would rather be on 9.

If a diagnostic build with extra logging in the new CoreAudio layer would help, send it over and I will run it and report back the same day. Same for any other test you want.

[Vibehunter]

9.0.1 still deadlocks here, and I think the fix is one layer too high

Thanks for 0db10a8974. I tested 9.0.1 on the same machine that produced the original report and the hang is still there, in the same function, with the same terminal frames. The stack shows where I think the fix needs to move.

Setup (unchanged from the original report): macOS 13.7.8, Intel Mac Pro (Xeon W-3235), Apogee Symphony I/O Mk II over Thunderbolt, 19 CoreAudio devices present (the Symphony, several virtual loopback devices, NDI, Pro Tools bridges, BlackHole, and some aggregates). The Apogee DEXT driver com.apogeedigital.TBTDriver 1.0.20 is loaded, and the older kext com.apogeedigital.kextSymphonyIO2T 0.8.7 is still registered alongside it.

Build: JUCE at tag 9.0.1, our tree unchanged, x86_64 Release. It compiles clean with zero warnings and our full DSP test suite passes 100% against 9.0.1, so the problem is only the live device layer.

What happens: the app never reaches its event loop. We have a launch watchdog on a background thread, so it keeps running while the message thread is blocked, and it reported the app still starting at 15.4 s, 31.4 s and 46.7 s with no window ever appearing. sample shows 100% of 4027 samples on the main thread in one stack:

juce::CoreAudioClasses::CoreAudioIODevice::getInputLatencyInSamples()  + 217
  AudioObjectGetPropertyDataSize                                      (in CoreAudio) + 137
    HALPlugIn::ObjectHasProperty(HALObject const&, AudioObjectPropertyAddress const&) const + 36
      HAL_HardwarePlugIn_ObjectHasProperty(AudioHardwarePlugInInterface**, unsigned int, AudioObjectPropertyAddress const*) + 429
        HALC_ShellObject::HasProperty(unsigned int, AudioObjectPropertyAddress const&, bool&) const + 692
          HALC_ProxyObject::HasProperty(AudioObjectPropertyAddress const&, bool&) const + 147
            mach_msg -> mach_msg_overwrite -> mach_msg2_internal -> mach_msg2_trap

The point. The commit message for 0db10a8974 says to rely on Get/IsProperty* failures instead of AudioObjectHasProperty, and getInputLatencyInSamples now goes through AudioObjectGetPropertyDataSize. But on this device CoreAudio's own HAL implements AudioObjectGetPropertyDataSize on top of HALPlugIn::ObjectHasProperty, which lands in exactly the same HALC_ProxyObject::HasProperty synchronous round-trip that never returns. The public API changed; the IPC underneath did not. Avoiding AudioObjectHasProperty at the JUCE level is not sufficient, because the property-existence check still happens inside CoreAudio whichever of the three entry points you call.

That is consistent with the three diagnostics you asked us to run last July: patching hasProperty() to return true unconditionally got the app past the deadlock, and enabling JUCE_COREAUDIO_LOGGING_ENABLED only moved the hang, to AudioObjectShow in the AudioObject constructor. Same HALC_ProxyObject -> mach_msg mechanism, different call site. It was never one specific selector: once the full device list is checked out, this device's HAL proxy stops answering synchronous property round-trips at all.

What I think would actually fix it, as far as I can tell from the outside: the latency queries need to tolerate a non-responsive device rather than block the thread that is building the audio device. A timeout, a documented default when the query cannot be satisfied, or moving the latency interrogation off the thread that must return for the app to launch. Any of those turns a hang into a wrong-but-alive latency number, which is recoverable. Blocking indefinitely on mach_msg during device setup is not.

Worth adding for anyone else who hits this: killing the wedged client wedged coreaudiod itself, after which even our JUCE 8.0.13 build blocked, at CoreAudioIODevice::start() -> AudioDeviceStart -> mach_msg. A sudo killall coreaudiod cleared it. So this is not a nice one to reproduce casually on a working machine.

Happy to run any diagnostic build you want, same as before. I can also do a clean stock-JUCE A/B, or strip the stale Apogee kext if you want to know whether the double registration is a factor. Just say which is more useful and I will get it done.