Summary:ASTERISK-10405: Random crash in frame.c:328
Reporter:ast rep (ast_rep)Labels:
Date Opened:2007-09-28 06:59:57Date Closed:2007-10-02 11:58:43
Versions:Frequency of
Environment:Attachments:( 0) bt_full.txt
Description:We have been experiencing a series of random crashes on our Asterisk
production systems.

gdb's backtrace looks exactly the same for all of the core dumps we

Versions used:

asterisk 1.4.11 (with tx and rx fax compiled)
libpri 1.4.1
spandsp 0.0.3
fedora core 4

There's some cases where Asterisk won't crash at all for days. Some other
days, it makes up to seven crashes a day.

We are using Asterisk with about 200 SIP Grandstream phones, we also have
two queues with four SIP members, a dual span E1, and one IAX trunk with
another asterisk 1.4.6

Here is the bt output

(gdb) bt
#0  0x00a0d402 in __kernel_vsyscall ()
#1  0x00aa71f8 in raise () from /lib/libc.so.6
#2  0x00aa8948 in abort () from /lib/libc.so.6
#3  0x00adc52a in __libc_message () from /lib/libc.so.6
#4  0x00ae2424 in _int_free () from /lib/libc.so.6
ASTERISK-1  0x00ae295f in free () from /lib/libc.so.6
ASTERISK-2  0x080a87f3 in frame_cache_cleanup (data=0x98dbce8) at frame.c:328
ASTERISK-3  0x00bf0b7a in __nptl_deallocate_tsd () from /lib/libpthread.so.0
ASTERISK-4  0x00bf1b8e in start_thread () from /lib/libpthread.so.0
ASTERISK-5  0x00b49dee in clone () from /lib/libc.so.6

bt full and thread apply all bt are in the uploaded txt.

Any clues?
Comments:By: Dmitry Andrianov (dimas) 2007-09-30 09:22:33

You are saying you have rxfax/txfax compiled, but do you use it? There is a bug in these applications which under some circumstances may lead to memory corruption. (more on this in issue 10815)

If I were you, I would run asterisk under valgrind to find where memory gets corrupt.

By: Jason Parker (jparker) 2007-10-02 11:58:42

I'm going to close this, and assume that the problem is as dimas says.  Please reopen if you can show that isn't the case.