Mutex lock failed error on addTimeSliceClient

Development
1

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!

Screenshot 2023-10-30 at 17.00.58
Screenshot 2023-10-30 at 17.00.581602×1094 142 KB

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
2

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.

1 Like
3

Did you solve this? Having a similar issue reported from client crash reporting, but struggling to re-create,

4

Can’t remember now but it was definitely tsan that helped me discover the issue.

5

Thanks for your reply! I took the easy way out in the end and coded out the need for the mutex in the end, but will def use that tool next time I have some synchronisation bug (of which I think there are a few hiding in the code).