Summary:	ASTERISK-16958: Random Crash
Reporter:	Kenneth Van Velthoven (kvveltho)	Labels:
Date Opened:	2010-11-15 05:10:32.000-0600	Date Closed:	2011-07-27 13:12:05
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt ( 1) backtraceNEW.txt ( 2) gdb_latest.txt ( 3) gdb.txt ( 4) gdb2.txt ( 5) gdbNEW.txt
Description:	There are about 100 cc calls + 10 chanspy channels on server + 1 queue About 80 regsitered accounts. ****** STEPS TO REPRODUCE ****** Unable to reproduce. ****** ADDITIONAL INFORMATION ****** Anyone has an idea on what it crashes?
Comments:	By: Kenneth Van Velthoven (kvveltho) 2010-11-23 04:09:45.000-0600 Can anyone look at this?   Meanwhile the server has crashed randomly every day. By: David Woolley (davidw) 2010-11-23 05:30:16.000-0600 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. By: Kenneth Van Velthoven (kvveltho) 2010-11-29 10:40:44.000-0600 I've enabled thread debugging.   New gdb.txt attached.   Hope this helps. By: Kenneth Van Velthoven (kvveltho) 2010-12-03 10:46:49.000-0600 2 crashes today.  Can anyone give me a clue? Meanwhile I've checked the memory with several tools and there are no errors. The server has 4GB.  I suppose this is enough? Any other logs/debug that may help you? Thanks in advance. By: David Brillert (aragon) 2010-12-03 11:58:04.000-0600 I am not a developer so I will not be of any help with debugging this problem but your gdb trace is not going to be of any help since the values in the trace are optmized out. Please see the doc/backtrace.txt file in your Asterisk source directory. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then: make install after enabling, reproduce the crash, and then execute the instructions in doc/backtrace.txt. When complete, attach that file to this issue report. By: Leif Madsen (lmadsen) 2010-12-06 13:13:09.000-0600 The new links for backtraces and valgrind are here: Backtraces: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace Valgrind: https://wiki.asterisk.org/wiki/display/AST/Valgrind By: Kenneth Van Velthoven (kvveltho) 2010-12-07 04:50:14.000-0600 backtrace.txt and gdblatest attached with DONT_OPTIMIZE en THREAD_DEBUGGING enabled By: David Brillert (aragon) 2010-12-07 08:05:55.000-0600 I noticed the wrong syntax in your attachment when executing the backtrace command. 'Undefined command: "btfull".  Try "help".' If you still have the backtrace then execute these commands bt bt full By: Kenneth Van Velthoven (kvveltho) 2010-12-07 08:19:50.000-0600 added backtraceNEW and gbdNEW Commands done: set logging on bt bt full thread apply all bt By: Russell Bryant (russell) 2011-07-27 13:12:00.832-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!