I’m porting an app that was originally developed for mobile to desktop for testing.
The app uses a TimeSliceClient to analyse audio data.
I am hitting the following exception from the
addTimeSliceClient
call: (macOS, clang, arm64)
libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
I’m a bit stuck with how to debug this. Any pointers would be greatly appreciated!
Here is the stack up until the application specific code:
__pthread_kill 0x0000000197c18724
pthread_kill 0x0000000197c4fc28
abort 0x0000000197b5dae8
abort_message 0x0000000197c08b84
demangling_terminate_handler() 0x0000000197bf83b4
_objc_terminate() 0x00000001978cf03c
std::__terminate(void (*)()) 0x0000000197c07f48
__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) 0x0000000197c0ad34
__cxa_throw 0x0000000197c0ace0
std::__1::__throw_system_error(int, char const*) 0x0000000197b868b4
std::__1::mutex::lock() 0x0000000197b7af88
std::lock_guard::lock_guard[abi:v15006](std::mutex &) __mutex_base:94
std::lock_guard::lock_guard[abi:v15006](std::mutex &) __mutex_base:94
juce::WaitableEvent::signal() const juce_WaitableEvent.cpp:59
juce::Thread::notify() const juce_Thread.cpp:295
juce::TimeSliceThread::addTimeSliceClient(juce::TimeSliceClient *, int) juce_TimeSliceThread.cpp:43
A quick google suggests this might occur if the mutex is being created or destroyed at the time .lock() is called on the mutex (Which happens on the first line of signal()). Is the TimeSliceThread potentially being destroyed on another thread?
Probably the best bet is to enable the Thread Sanitiser and see what that shows up.
