Unlock of an os_unfair_lock not owned by current thread

Anybody seen this error before:

BUG IN CLIENT OF LIBPLATFORM: Unlock of an os_unfair_lock not owned by current thread

Thread 0 Crashed:: JUCE Message Thread Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib      	       0x18d57d1dc _os_unfair_lock_unowned_abort + 36
1   libsystem_platform.dylib      	       0x18d57886c _os_unfair_lock_unlock_slow + 96
2   libsystem_pthread.dylib       	       0x18d5472dc _pthread_cond_check_init_slow + 308
3   libsystem_pthread.dylib       	       0x18d546f14 pthread_cond_broadcast + 140
4   libc++.1.dylib                	       0x18d474ec8 std::__1::condition_variable::notify_all() + 16
5   V-Control Pro                 	       0x104e5a260 juce::WaitableEvent::signal() const + 48
6   V-Control Pro                 	       0x104f21e88 juce::MessageManager::Lock::abort() const + 28
7   V-Control Pro                 	       0x104f23ea4 juce::MessageManager::Lock::BlockingMessage::messageCallback() + 56
8   V-Control Pro                 	       0x104f25d68 juce::MessageQueue::deliverNextMessage() + 60
9   V-Control Pro                 	       0x104f25d08 juce::MessageQueue::runLoopCallback() + 36
10  CoreFoundation                	       0x18d62a710 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
11  CoreFoundation                	       0x18d62a6a4 __CFRunLoopDoSource0 + 176
12  CoreFoundation                	       0x18d62a414 __CFRunLoopDoSources0 + 244
13  CoreFoundation                	       0x18d62901c __CFRunLoopRun + 828
0   libsystem_kernel.dylib        	       0x18d50f710 __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18d54c574 _pthread_cond_wait + 1232
2   libc++.1.dylib                	       0x18d474ef0 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
3   V-Control Pro                 	       0x104e5a0c8 juce::WaitableEvent::wait(int) const + 156
4   V-Control Pro                 	       0x104f21da0 juce::MessageManager::Lock::tryAcquire(bool) const + 256
5   V-Control Pro                 	       0x104f21f7c juce::MessageManagerLock::attemptLock(juce::Thread*, juce::ThreadPoolJob*) + 108
6   V-Control Pro                 	       0x104f21ee0 juce::MessageManagerLock::MessageManagerLock(juce::Thread*) + 76

I have another thread trying to grab the message manager lock and then the main thread blows up.

Is this commit (MessageManager: Improve thread safety of Lock type · juce-framework/JUCE@33e8161 · GitHub) to resolve this issue?

No, it was to fix this one:

It’s possible that the issues have the same underlying cause.