<div dir="ltr"><div><div><div><div><div><div>While testing the patch of <a href="https://issues.asterisk.org/jira/browse/ASTERISK-24983">https://issues.asterisk.org/jira/browse/ASTERISK-24983</a>, I found that in some paths (ex. in call hangup procedure) we acquire the lock multiple times from the same thread.<br><br></div>The lock implementation supports reentrant locks, so it works; until you stuck in a deadlock!<br><br></div>For example (lock iaxs[callno]), the function iax2_destroy_helper is called from multiple paths:<br></div> 1 - iax2_hangup -> iax2_destroy_helper : In this path the lock is locked only once (in iax2_hangup).<br><br></div> 2 - socket_process_helper (ACK for hangup) -> iax2_destroy -> pvt_destructor (because of ao2_ref(pvt,-1) -> iax2_destroy_helper : In this path lock is locked twice, one in socket_process_helper and the other in pvt_destructor.<br><br></div>The problem of this is that in function iax2_destroy_helper, I wanted to avoid deadlock with other thread (sending scheduled lagrq), so I did ast_mutex_unlock. But I still got deadlock!!<br><br></div>Why? Because you need to unlock it twice in path 2!<br><br><div><div><div><div><div><div><div>Personally, I didn't like it that much.<br><br></div><div>Is it common, and we live with it (will do a work around for this specific case)?<br><br>Or this seems trouble making pattern and we should have deeper look (probably in IAX and other components)?<br><br></div><div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Yousf Ateya,<br></div><div></div><div>StarkBits</div><div><a href="http://www.starkbits.com" target="_blank">www.starkbits.com</a></div></div></div></div></div>
</div></div></div></div></div></div></div></div>
<br>
<pre><font size="1" face="Courier New">This e-mail message is intended only for the use of the intended recipient(s).
The information contained therein may be confidential or privileged,
and its disclosure or reproduction is strictly prohibited.
If you are not the intended recipient, please return it immediately to its sender
at the above address and destroy it.
</font></pre>