[Bug]: uncaught exception of type std::__1::system_error with enabled ThreadSanitizer on quit

[vhlukhov]

Detailed steps on how to reproduce the bug

When utilizing the JUCE Framework with ThreadSanitizer enabled, the application is unable to properly terminate the application.

1. cmake -G Xcode -B Build -DJUCE_BUILD_EXTRAS=ON -DJUCE_BUILD_EXAMPLES=ON
2. Select DemoRunner and enable the ThreadSanitizer
3. Launch the application
4. Quit application
5. The debugger will stop when an error is detected, which will cause std::terminate.

libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument

This behavior is reproduced on all versions of Xcode 15.x. It's hard to tell if it was reproduced on macOS Sonoma earlier versions.

What is the expected behaviour?

The application should close correctly without errors.

Operating systems

macOS

What versions of the operating systems?

macOS Sonoma 14.6.1. M1 Pro 16gb RAM

Architectures

ARM

Stacktrace

(lldb) bt all
  thread #1, name = 'JUCE Message Thread', queue = 'com.apple.main-thread'
    frame #0: 0x000000018109c3e8 libsystem_kernel.dylib`__semwait_signal + 8
    frame #1: 0x0000000180f7d568 libsystem_c.dylib`nanosleep + 220
    frame #2: 0x0000000180f7d480 libsystem_c.dylib`usleep + 68
    frame #3: 0x0000000106ea758c libclang_rt.tsan_osx_dynamic.dylib`__tsan::Finalize(__tsan::ThreadState*) + 124
    frame #4: 0x0000000106e8c32c libclang_rt.tsan_osx_dynamic.dylib`__tsan::finalize(void*) + 24
    frame #5: 0x0000000180f972e8 libsystem_c.dylib`__cxa_finalize_ranges + 476
    frame #6: 0x0000000180f97070 libsystem_c.dylib`exit + 44
    frame #7: 0x00000001810f2850 libdyld.dylib`dyld4::LibSystemHelpers::exit(int) const + 20
    frame #8: 0x0000000180d4f1a0 dyld`start + 2552
* thread #4, queue = 'com.app.gputools.telemetry', stop reason = signal SIGABRT
  * frame #0: 0x00000001810a15f0 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000106e06be8 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x0000000106e7b6d8 libclang_rt.tsan_osx_dynamic.dylib`wrap_pthread_kill + 268
    frame #3: 0x0000000180fe6a30 libsystem_c.dylib`abort + 180
    frame #4: 0x0000000106e7a84c libclang_rt.tsan_osx_dynamic.dylib`wrap_abort + 128
    frame #5: 0x0000000181090d08 libc++abi.dylib`abort_message + 132
    frame #6: 0x0000000181080fa4 libc++abi.dylib`demangling_terminate_handler() + 320
    frame #7: 0x0000000180d1bc00 libobjc.A.dylib`_objc_terminate() + 160
    frame #8: 0x00000001810900cc libc++abi.dylib`std::__terminate(void (*)()) + 16
    frame #9: 0x0000000181090070 libc++abi.dylib`std::terminate() + 108
    frame #10: 0x0000000180d372dc libobjc.A.dylib`objc_terminate + 16
    frame #11: 0x0000000106d5ebb8 libdispatch.dylib`_dispatch_client_callout + 40
    frame #12: 0x0000000106d6242c libdispatch.dylib`_dispatch_continuation_pop + 704
    frame #13: 0x0000000106d7dbfc libdispatch.dylib`_dispatch_source_latch_and_call + 488
    frame #14: 0x0000000106d7c2b4 libdispatch.dylib`_dispatch_source_invoke + 868
    frame #15: 0x0000000106d67b98 libdispatch.dylib`_dispatch_lane_serial_drain + 368
    frame #16: 0x0000000106d68e7c libdispatch.dylib`_dispatch_lane_invoke + 416
    frame #17: 0x0000000106d78958 libdispatch.dylib`_dispatch_root_queue_drain_deferred_wlh + 652
    frame #18: 0x0000000106d77c30 libdispatch.dylib`_dispatch_workloop_worker_thread + 444
    frame #19: 0x0000000106e07d40 libsystem_pthread.dylib`_pthread_wqthread + 288
  thread #5
    frame #0: 0x000000018109c3e8 libsystem_kernel.dylib`__semwait_signal + 8
    frame #1: 0x0000000180f7d568 libsystem_c.dylib`nanosleep + 220
    frame #2: 0x0000000180f7d480 libsystem_c.dylib`usleep + 68
    frame #3: 0x0000000106ea9028 libclang_rt.tsan_osx_dynamic.dylib`__tsan::BackgroundThread(void*) + 192
    frame #4: 0x0000000106e055c0 libsystem_pthread.dylib`_pthread_start + 136
  thread #11
    frame #0: 0x0000000181098df4 libsystem_kernel.dylib`mach_msg2_trap + 8
    frame #1: 0x00000001810ab5e4 libsystem_kernel.dylib`mach_msg2_internal + 80
    frame #2: 0x00000001810a19c4 libsystem_kernel.dylib`mach_msg_overwrite + 476
    frame #3: 0x0000000181099178 libsystem_kernel.dylib`mach_msg + 24
    frame #4: 0x000000019b301094 CoreMIDI`XServerMachPort::ReceiveMessage(int&, void*, int&) + 104
    frame #5: 0x000000019b31257c CoreMIDI`MIDIProcess::MIDIInPortThread::Run() + 156
    frame #6: 0x000000019b30f908 CoreMIDI`CADeprecated::XThread::RunHelper(void*) + 48
    frame #7: 0x000000019b3115cc CoreMIDI`CADeprecated::CAPThread::Entry(CADeprecated::CAPThread*) + 92
    frame #8: 0x0000000106e785b0 libclang_rt.tsan_osx_dynamic.dylib`__tsan_thread_start_func + 144
    frame #9: 0x0000000106e055c0 libsystem_pthread.dylib`_pthread_start + 136
  thread #12, name = 'caulk.messenger.shared:17'
    frame #0: 0x0000000181098d70 libsystem_kernel.dylib`semaphore_wait_trap + 8
    frame #1: 0x000000018b658624 caulk`caulk::semaphore::timed_wait(double) + 212
    frame #2: 0x000000018b6584d8 caulk`caulk::concurrent::details::worker_thread::run() + 36
    frame #3: 0x000000018b6581d8 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 96
    frame #4: 0x0000000106e785b0 libclang_rt.tsan_osx_dynamic.dylib`__tsan_thread_start_func + 144
    frame #5: 0x0000000106e055c0 libsystem_pthread.dylib`_pthread_start + 136
  thread #13, name = 'caulk.messenger.shared:high'
    frame #0: 0x0000000181098d70 libsystem_kernel.dylib`semaphore_wait_trap + 8
    frame #1: 0x000000018b658624 caulk`caulk::semaphore::timed_wait(double) + 212
    frame #2: 0x000000018b6584d8 caulk`caulk::concurrent::details::worker_thread::run() + 36
    frame #3: 0x000000018b6581d8 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 96
    frame #4: 0x0000000106e785b0 libclang_rt.tsan_osx_dynamic.dylib`__tsan_thread_start_func + 144
    frame #5: 0x0000000106e055c0 libsystem_pthread.dylib`_pthread_start + 136
  thread #17, name = 'com.apple.NSEventThread'
    frame #0: 0x0000000181098df4 libsystem_kernel.dylib`mach_msg2_trap + 8
    frame #1: 0x00000001810ab5e4 libsystem_kernel.dylib`mach_msg2_internal + 80
    frame #2: 0x00000001810a19c4 libsystem_kernel.dylib`mach_msg_overwrite + 476
    frame #3: 0x0000000181099178 libsystem_kernel.dylib`mach_msg + 24
    frame #4: 0x00000001811b9680 CoreFoundation`__CFRunLoopServiceMachPort + 160
    frame #5: 0x00000001811b7f44 CoreFoundation`__CFRunLoopRun + 1208
    frame #6: 0x00000001811b7434 CoreFoundation`CFRunLoopRunSpecific + 608
    frame #7: 0x0000000184b41280 AppKit`_NSEventThread + 144
    frame #8: 0x0000000106e785b0 libclang_rt.tsan_osx_dynamic.dylib`__tsan_thread_start_func + 144
    frame #9: 0x0000000106e055c0 libsystem_pthread.dylib`_pthread_start + 136
  thread #19
    frame #0: 0x0000000106e0fa8c libsystem_pthread.dylib`start_wqthread
  thread #21
    frame #0: 0x0000000106e0fa8c libsystem_pthread.dylib`start_wqthread
  thread #22
    frame #0: 0x0000000106e0fa8c libsystem_pthread.dylib`start_wqthread

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

• [X] I agree to follow the Code of Conduct

[Anthony-Nicholls]

I've taken a quick look at this. I can reproduce the issue but it's difficult to know what to conclude.

• It happens on JUCE versions dating back to at least 7.0.0 (I haven't tested anything older)
• JUCE console applications appear unaffected
• JUCE plugins appear unaffected (tested using VST3 in Reaper)
• It happens in multiple Xcode versions (tested with 15.4, and 16.1 Beta)
• The crash occurs after the main function has returned
• No JUCE code appears to be in the stack of any of the threads when it crashes

If it is a fault in JUCE causing the issue it must be something with global or static duration, however having not seen this in the past or heard other reports, given the information above, and that such a crash is normally the result of a threading issue which the thread sanitiser should pick up, and it only happens when the thread snazzier is enabled, I feel the only logical conclusion is that thread sanitiser is somehow at fault?

• It might be nice to confirm this doesn't happen on some older versions of Xcode/macOS. Unfortunately I can't run Xcode 14 versions on my Sonoma machine
• It would also be nice to reproduce the issue with a smaller project, the best I managed was a blank JUCE GUI app for now