[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:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   11080
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     feedback
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-12-2007 10:01 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-12-07 10:01  
---------------------------------------------------------------------- 
russell: we just had another occurrence of this problem. Running on 1.4
r89088. Asterisk was in a state where it wouldn't allow console
connections, but was running - so we couldn't get a core show locks. If you
look at the thread apply all bt I've attached, you can see there is memory
corruption in threads 6,9 & 11. 

The one thing these all have in common is that they seem to be referencing
the same part of the lock debugging code (it could be that it is unrelated,
but I thought I'd bring it up). 

Otherwise, two of them (9 & 11) seem to be in devicestate.c and related to
hints, the third (6) appears to be in channel.c. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-12-07 10:01  callguy        Note Added: 0073518                          
======================================================================