Summary:ASTERISK-16958: Random Crash
Reporter:Kenneth Van Velthoven (kvveltho)Labels:
Date Opened:2010-11-15 05:10:32.000-0600Date Closed:2011-07-27 13:12:05
Versions:Frequency of
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.


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:



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 full

By: Kenneth Van Velthoven (kvveltho) 2010-12-07 08:19:50.000-0600

added backtraceNEW and gbdNEW

Commands done:
set logging on
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!