[asterisk-bugs] [Asterisk 0018403]: [patch] Deadlock on SIP blind transfer (REFER)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18403 
====================================================================== 
Reported By:                jthurman
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18403
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                       SWP-2667 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.8 
SVN Revision (number only!): 296824 
Request Review:              
====================================================================== 
Date Submitted:             2010-11-30 18:25 CST
Last Modified:              2010-12-23 14:43 CST
====================================================================== 
Summary:                    [patch] Deadlock on SIP blind transfer (REFER)
Description: 
All SIP:
- A calls B
- B blind-transfers A to C (Using REFER)
- Asterisk stops responding to SIP requests (Deadlocked)

====================================================================== 

---------------------------------------------------------------------- 
 (0129927) kkm (reporter) - 2010-12-23 14:43
 https://issues.asterisk.org/view.php?id=18403#c129927 
---------------------------------------------------------------------- 
I looked at your original trace, and it does not look like a deadlock to
me. There is no note "Locked Here" on your do_monitor thread()! Yes, the
locks *look* like they are taken in the wrong order, but
do_handle_request() goes a great length to upgrade the pvt lock to a
channel lock, and does that correctly.

In fact, the monitor thread is not locked, but looping in
ast_autoservice_stop(). If you look at its code, there is a loop of the
form

while (/* autoservice thread not completed iteration */) sleep 1 ms.

Now, I do not understand why autoservice is blocking. In the backtrace, it
is blocked on the channel lock, but that block is limited to 50 ms. If
unable to obtain lock, the autoservice thread would just start a new
iteration, incrementing the counter and thus releasing monitor. That does
not happen, and I am completely at loss as to why. ast_wait_n() supposed to
return a failure in only 50 ms of waiting and hit the continue statement.
Please debug that when you get the deadlock (that's all without your
changes, on the original code).

Oh, and with your patch we are getting a real first class deadlock.
pbx_builtin_setvar_helper() tries to obtain the channel lock, but, absent
the caution of handle_request_do() in doing so, easily deadlocks. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-12-23 14:43 kkm            Note Added: 0129927                          
======================================================================