search

juce-framework / JUCE

JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.
https://juce.com
Other
6.68k stars 1.75k forks source link

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

Open vhlukhov opened 3 months ago

vhlukhov commented 3 months ago

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.

image
  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

Anthony-Nicholls commented 3 months ago

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

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?