|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|
|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:
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:
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
By: Kenneth Van Velthoven (kvveltho) 2010-12-07 08:19:50.000-0600
added backtraceNEW and gbdNEW
set logging on
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!