# Confusion about deadlock in AudioProcessorParameter class after update to JUCE 6

**URL:** <https://forum.juce.com/t/confusion-about-deadlock-in-audioprocessorparameter-class-after-update-to-juce-6/43752>\
**Category:** General JUCE discussion\
**Created:** [January 11, 2021, 4:31pm UTC](https://forum.juce.com/t/confusion-about-deadlock-in-audioprocessorparameter-class-after-update-to-juce-6/43752 "2021-01-11T16:31:27Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\
**Post date:** [January 11, 2021, 4:31pm UTC](https://forum.juce.com/t/confusion-about-deadlock-in-audioprocessorparameter-class-after-update-to-juce-6/43752/1 "2021-01-11T16:31:27Z")

</div>

I’m updating an older plugin project from JUCE 5 to JUCE 6. After the update, the plugin now runs into a deadlock on the message thread here

 ![image (5)](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/2/26f4df309c3e0d97c6b1af9b55a441c25d93741e.png)

Going up the call stack quite a bit (45 sub-function calls), I’m reaching this member function call, called on the same `AudioProcessorParameter` instance

 ![image (6)](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/b/b515f4788a626d974b7065da72e7cc19ebef3447.png)

Which shows me that the lock is already held on the message thread. According to the `CriticalSection` documentation which says

> If the lock is already held by the caller thread, the method returns immediately

the thread should not wait here. Still it does. A simple test application could not reproduce this issue.

Note that I do see the possible danger here in deleting a listener while iterating over the listeners, this will be definetively addressed. But for now, I’d really like to understand why this deadlock happens here. Anything stupid that I might overlook?

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [January 11, 2021, 6:31pm UTC](https://forum.juce.com/t/confusion-about-deadlock-in-audioprocessorparameter-class-after-update-to-juce-6/43752/2 "2021-01-11T18:31:49Z")

</div>

Are you absolutely sure that the _same_ lock is being locked in both functions here? If you have multiple parameters, it’s possible you might be calling ‘removeListener’ on a separate parameter to the one which called `sendValueChangedMessageToListeners`.

---

<div class="post-metadata">

**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\
**Post date:** [January 12, 2021, 11:15am UTC](https://forum.juce.com/t/confusion-about-deadlock-in-audioprocessorparameter-class-after-update-to-juce-6/43752/3 "2021-01-12T11:15:04Z")

</div>

Yeah, turns out that it was a different lock in the end and a parameter change coming in from a different thread held it – so a classic deadlock in the end but a really really hidden one – took me hours of going through legacy code mostly not written by me 😬

Tbh it would have really surprised me if there had been a real issue with the `CriticalSection` here that wouldn’t have been discovered before…

But as a question arising from that, is there any clever way of debugging which thread holds the lock for the underlying `pthread_mutex` in such scenarios that does not involve the manual search I had to perform here?

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [January 12, 2021, 11:32am UTC](https://forum.juce.com/t/confusion-about-deadlock-in-audioprocessorparameter-class-after-update-to-juce-6/43752/4 "2021-01-12T11:32:02Z")

</div>

> [@PluginPenguin](#):
>
> But as a question arising from that, is there any clever way of debugging which thread holds the lock for the underlying `pthread_mutex` in such scenarios that does not involve the manual search I had to perform here?

Not particularly clever, but you could adjust the implementation of `CriticalSection::enter` to store the result of `std::this_thread::get_id()` into a data member after successfully gaining the lock. Then, when the deadlock ocurrs, you can inspect this data member to find which thread locked the mutex.