[asterisk-bugs] [Asterisk 0018403]: 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-19 14:06 CST
====================================================================== 
Summary:                    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)

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

---------------------------------------------------------------------- 
 (0129774) kkm (reporter) - 2010-12-19 14:06
 https://issues.asterisk.org/view.php?id=18403#c129774 
---------------------------------------------------------------------- 
I cannot reproduce yet, but we are using REFER a lot, so I am very
concerned.

Copying Russel Bryant's response on asterisk-dev:

<<<
I just took a look.  The "core show locks" output is what is most helpful
to me in seeing where the problem is.

This problem is one of the more common deadlock situations that come up in
Asterisk.  There is a lock associated with the ast_channel as well as a
lock for the private data in the channel driver (sip_pvt in this case). 
Based on Asterisk locking rules, it is only safe to lock the ast_channel
first, and the sip_pvt second.  Otherwise, a deadlock avoidance technique
of some kind must be used.

The bug is in the do_monitor thread in the "core show locks" output.  In
that thread, you can see these locks:

    1) netlock (irrelevant to this bug)
    2) sip_pvt (variable i in sip_new)
    3) channel <--- Blocking while waiting for this lock

The bug here is that the code is trying to lock the ast_channel while
holding the sip_pvt lock.  There are a few different solutions, and which
one is most appropriate requires more in depth investigation of the code
path in question.

1) Unlock the sip_pvt before doing anything that is going to try to grab
the channel lock.

2) If you must hold both the sip_pvt and the channel lock at the same
time, you can either:

2.a) lock the channel first, then the pvt (not usually an option,
actually).

2.b) Acquire both locks using a deadlock avoidance loop like this:

    lock(sip_pvt);
    while (trylock(ast_channel)) {
        unlock(sip_pvt);
        sched_yield();
        lock(sip_pvt);
    }

    ... do whatever ...

    unlock(ast_channel);
    unlock(sip_pvt);
>>> 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-12-19 14:06 kkm            Note Added: 0129774                          
======================================================================