[asterisk-bugs] [Asterisk 0018890]: Error obtaining mutex in channel.c

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18890 
====================================================================== 
Reported By:                absystech
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18890
Category:                   Core/Channels
Reproducibility:            sometimes
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.16.2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-02-25 08:49 CST
Last Modified:              2011-02-25 11:09 CST
====================================================================== 
Summary:                    Error obtaining mutex in channel.c
Description: 
Core crash after incoming calls on DAHDI or on transfer between incoming
calls on DAHDI and SIP peers.

SIP Account 5630 is a receptionist phone and it intercept incoming calls
wich arrive in the queue called "Standard".
Maybe it crashes on a transfert between 5630 and 7662, maybe on incoming
calls...
====================================================================== 

---------------------------------------------------------------------- 
 (0132411) davidw (reporter) - 2011-02-25 11:09
 https://issues.asterisk.org/view.php?id=18890#c132411 
---------------------------------------------------------------------- 
This sort of problem is always due to a design error in Asterisk.  A lot of
complex activity tends to bring it out, because it increases the chances of
two events happening with just the right timing relationship.  When we've
found this sort of thing, it always has to be fixed in the source code (we
are using an old version, so we often back port fixes from later
versions).

If you can make a good guess at what is going wrong, you can often add a
call to sleep in the source code, which makes the problem repeatable, for
debugging and verification of the fix.

Workarounds are not really the job of the issue tracker, but the only
workaround I know of, at least without a detailed understanding of the
particular failure, is to run on a single processor, single core machine
(or simulating this with processor affinity), as this greatly reduces the
opportunities, although doesn't remove them. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-25 11:09 davidw         Note Added: 0132411                          
======================================================================