<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1171/">https://reviewboard.asterisk.org/r/1171/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 13th, 2011, 4:03 a.m., <b>astmiv</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">It appears that locking a pvt is done without checking if the owner of the pvt is also locked. I have reported another issue 19107 which has the same deadlock problem with one other different location.
One thread is first locking the channel and then would like to lock pvt while another first locks the pvt and then would like to lock the channel.
When I read through the code in sip_chan.c i conclude that the channel (pvt->owner) should always be locked first before locking the pvt. Is this right?
I think we should make a solution which fixes this in every possible situation.</pre>
</blockquote>
<p>On April 13th, 2011, 4:10 a.m., <b>astmiv</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">/* since p->owner (c) is unlocked, we need to go ahead and unlock pvt for both
* magic pickup and ast_hangup. Both of these functions will attempt to lock
* p->owner again, which can cause a deadlock if we already hold a lock on p.
* Locking order is, channel then pvt. Dead lock avoidance must be used if
* called the other way around. */
>From sip_chan.c in function handle_request_invite()</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yip it gets ugly down there thx for the feedback ill be looking into it further this patch wont fix it it was a "quick" look and slash im working it at the momment.</pre>
<br />
<p>- irroot</p>
<br />
<p>On April 13th, 2011, 3:17 a.m., irroot wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.orgrb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By irroot.</div>
<p style="color: grey;"><i>Updated 2011-04-13 03:17:24</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
Channel walk is contending a lock on a channel held by ast_write while sip_write is contending a private lock held by handle incoming that is contending the channel lock held by the write ...
now if i was holding the channel lock in handle_incoming before i locked private this would not happen ...
some how ive been appointed the deadlock fairy ... monitoring +/- 100 1.8 sites for deadlocks and attempt to fix them as they
popup.
=== Thread ID: 0xb3cf7b70 (do_devstate_changes started at [ 724] devicestate.c ast_device_state_engine_init())
=== ---> Lock #0 (astobj2.c): MUTEX 657 internal_ao2_callback c 0x85fe1b8 (1)
=== ---> Waiting for Lock #1 (channel.c): MUTEX 1641 ast_channel_cmp_cb chan 0xabb7a558 (1)
=== --- ---> Locked Here: channel.c line 4690 (ast_write)
=== -------------------------------------------------------------------
===
=== Thread ID: 0xabf3fb70 (do_monitor started at [24621] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 24593 do_monitor &monlock 0xb314fde0 (1)
=== ---> Lock #1 (chan_sip.c): MUTEX 23781 handle_incoming p 0xab7c94a8 (1)
=== ---> Waiting for Lock #2 (channel.c): MUTEX 1361 __ast_queue_frame chan 0xabb7a558 (1)
=== --- ---> Locked Here: channel.c line 4690 (ast_write)
=== -------------------------------------------------------------------
===
=== Thread ID: 0xab6c3b70 (pbx_thread started at [ 5038] pbx.c ast_pbx_start())
=== ---> Lock #0 (channel.c): MUTEX 4690 ast_write chan 0xabb7a558 (1)
=== ---> Waiting for Lock #1 (chan_sip.c): MUTEX 6083 sip_write p 0xab7c94a8 (1)
=== --- ---> Locked Here: chan_sip.c line 23781 (handle_incoming)
=== -------------------------------------------------------------------
=== </pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/view.php?id=19112">19112</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/1.8/channels/chan_sip.c <span style="color: grey">(313425)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1171/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>