[asterisk-bugs] [Asterisk 0011080]: SIP channel stops processing calls, but no apparent deadlock

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11080 
====================================================================== 
Reported By:                callguy
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11080
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-24-2007 15:58 CDT
Last Modified:              11-19-2007 23:53 CST
====================================================================== 
Summary:                    SIP channel stops processing calls, but no apparent
deadlock
Description: 
Approximately once per week we are seeing asterisk stop processing SIP
calls. The behavior is the same as a deadlock, but core show locks does not
show any evidence that there is a deadlock. 

The only way to resolve is to restart asterisk. 

output of:
core show locks
info thread
thread apply all bt

from the running process is attached.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0011165 Deadlock in channel.c
====================================================================== 

---------------------------------------------------------------------- 
 callguy - 11-19-07 23:53  
---------------------------------------------------------------------- 
russell: if you could point us in the right direction it would be a big
help.

from our initial read, it looked like the ast_mutex_locks/unlocks were
being handled individually within the functions in chan_sip.c (i.e. -
__sip_ack and others). this is why we couldn't quite understand why our
patch wasn't helping. 

Separately, we couldn't see why enst's suggested patch was helping, as
moving the locks outside the function would seem to be avoiding the issue,
but could lead to other potential problems. 

However, after tracing the code, it appears that sipsock_read is actually
getting the mutex lock, then calling handle_request, which in turn calls
handle_response, and then sipsock_read unlocks when it gets a return. Our
question is if p is already locked, why are the functions individually
locking it again (and why does that even work)?

We believe that we're seeing this in __sip_ack more frequently than other
functions because it is called the most frequently - hence giving the
highest probability of being the function that encounters the deadlock. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-19-07 23:53  callguy        Note Added: 0074035                          
======================================================================