[asterisk-bugs] [Asterisk 0018307]: Random Crash

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18307 
====================================================================== 
Reported By:                kvveltho
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18307
Category:                   Core/General
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.14 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-11-15 05:10 CST
Last Modified:              2010-11-23 05:30 CST
====================================================================== 
Summary:                    Random Crash
Description: 
There are about 100 cc calls + 10 chanspy channels on server + 1 queue
About 80 regsitered accounts.
====================================================================== 

---------------------------------------------------------------------- 
 (0129077) davidw (reporter) - 2010-11-23 05:30
 https://issues.asterisk.org/view.php?id=18307#c129077 
---------------------------------------------------------------------- 
If you don't have thread debugging enabled, recompile with it enabled.

At the least you have a problem with locking, possibly a double release. 
You may also have memory corruption, in which case you may need to follow
the instructions in valgrind.txt, but note that this will make Asterisk run
exceedingly slowly.

The standard error output would be useful (it may be on tty9, if you use
the standard safe_asterisk script, should give a better indication of why
the lock was damaged.

It looks like a call is being aborted. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-23 05:30 davidw         Note Added: 0129077                          
======================================================================