[Home]

Summary:ASTERISK-17891: [patch] Deadlock in chan_sip.c handle_incoming()
Reporter:Steve Davies (one47)Labels:
Date Opened:2011-05-19 08:33:37Date Closed:2011-05-23 09:47:51
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.6.2.18 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip_handle_incoming_deadlock
Description:There are several bug reports open which involve deadlocks in chan_sip.c handle_incomig() not having a channel lock held before a pvt lock:
   ASTERISK-17691
   ASTERISK-17681
   ASTERISK-17686

These deadlocks will apply to 1.6.2.18 and to 1.8.4, but I also believe that branches/1.8  and trunk/ already contain a fix that comes from https://reviewboard.asterisk.org/r/1182/ that removes this issue by removing the
request_queue from chan_sip.c completely.


****** ADDITIONAL INFORMATION ******

Attached is an alternative approach, which may be suitable for people running 1.4 and 1.6 - I prefer the fix in trunk, but it is a much bigger change, whereas this patch simply tries to fix the cause of the deadlock at source without changing the fundamental nature of the code.

Basically, when running the SIP request_queue, we call handle_incoming() which requires that we have both a channel lock and a pvt lock held.

The existing code assumes that we will a) keep that lock once we have it, and b) will not create a previously non-existent p->owner within handle_incoming(), that we will then not necessarily have locked.

The attached patch tries to ensure that if we discover that we have an unlocked channel, that we queue all remaining packets, and stop calling handle_incoming.
Comments:By: Steve Davies (one47) 2011-05-19 08:34:18

Currently compile checked only - Will report back after load testing.
By: Leif Madsen (lmadsen) 2011-05-23 09:46:47

After speaking with Russell, it's a bit too late to get this into 1.4 and 1.6, and as it has already been resolved in Asterisk 1.8 and later, I'd encourage you to move to 1.8 if this is an issue for you. Thanks!