[asterisk-bugs] [Asterisk 0014464]: lock during simple call processing

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14464 
====================================================================== 
Reported By:                pj
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14464
Category:                   Channels/chan_sip/General
Reproducibility:            unable to reproduce
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 171528 
Request Review:              
====================================================================== 
Date Submitted:             2009-02-12 06:27 CST
Last Modified:              2009-06-10 17:28 CDT
====================================================================== 
Summary:                    lock during simple call processing
Description: 
During normal operation, pure sip-sip calls, without special features (eg.
transfer), asterisk locks. Asterisk server had very small utilization -
three concurrent sip calls at maximum. After this lockout, all peers
becomed unreachable and asterisk must be manually restarted. CLI was not
locked.
"core show locks" attached

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

---------------------------------------------------------------------- 
 (0106269) mmichelson (administrator) - 2009-06-10 17:28
 https://issues.asterisk.org/view.php?id=14464#c106269 
---------------------------------------------------------------------- 
I just took a look at this, and it has me a bit baffled.

I can see from the "core show locks" output that the SIP monitor thread is
blocking at some point. The problem is that the corresponding thread in the
gdb output (thread 6) has a bunch of ?? frames. In addition, the portion of
the stack that is not ?? has garbage (e.g. free() does not call poll()).

It's very frustrating that the most important thread from the gdb output
is the only one that has garbage data in it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-10 17:28 mmichelson     Note Added: 0106269                          
======================================================================