[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-14-2007 21:48 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.
====================================================================== 

---------------------------------------------------------------------- 
 callguy - 11-14-07 21:48  
---------------------------------------------------------------------- 
Removing the locking from __sip_ack and placing it before where it is
called from within __sip_pretend_ack is the same balanced operation. But
would we need to also wrap the invocation of _sip_ack in handle_response()
and handle_request(),, as these two invocations would now invoke
__sip_ack() without having p->lock.

I think they issue is that the p->lock is being locked by find_call(),
which has ast_get_lock(p->lock) in two conditional places, but does not
unlock. the calling sipsock_read() was unlocking the p->lock in the normal
return of the function, however the error return on invalid sip packet was
not unlocking the p->lock.  so a subsequent call to sipsock_read()
following a previous lock and error exit from invalid sip packed would
still cause a deadlock there too, or the next time handle_request() or
handle_response() were called, which would in turn call the __sip_ack(),
which would deadlock because of the previously unbalanced unlocking of
p->lock from the error exit of invalid sip packed. 

see my new patch, where i remove the ast_get_lock(p->lock) from
find_call() and get the lock from within sipsock_read() where we can
clearly see my previous patch is required to balance the lock/ unlocking of
p->lock. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-14-07 21:48  callguy        Note Added: 0073666                          
======================================================================