| Summary: | ASTERISK-10405: Random crash in frame.c:328 | ||
| Reporter: | ast rep (ast_rep) | Labels: | |
| Date Opened: | 2007-09-28 06:59:57 | Date Closed: | 2007-10-02 11:58:43 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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 collected. Versions used: asterisk 1.4.11 (with tx and rx fax compiled) libpri 1.4.1 zaptel 1.4.5.1 spandsp 0.0.3 libtiff-3.7.1-6 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. | ||