Summary:ASTERISK-12735: Asterisk crash 1.4 SVN
Reporter:Doug (doug)Labels:
Date Opened:2008-09-16 09:00:21Date Closed:2008-09-23 11:32:08
Versions:Frequency of
Environment:Attachments:( 0) gdb.txt
( 1) gdb-27th-sep.txt
Description:We are often getting crashes on the SVN branch. I am not sure from the GDB output what is causing this so I have attached this info.

Comments:By: Joel Vandal (jvandal) 2008-09-16 09:18:50

I'm checking the gdb file, and here my understanding, please correct me if I'm wrong...

- Crash occur on the ast_cdr_start function so this is related to CDR

Program terminated with signal 11, Segmentation fault.
#0  0x08082fc3 in ast_cdr_start ()

- On thread 1, it start an AGI (dial.php) and on this script it do a ResetCDR.

By: Tilghman Lesher (tilghman) 2008-09-16 09:32:34

I'm going to need you to recompile with DONT_OPTIMIZE and try to reproduce this crash.  I need to be able to see debugging symbols in your backtrace, or else I cannot diagnose this issue.

By: Joel Vandal (jvandal) 2008-09-16 09:35:13

Hmm, asterisk is already compiled with this flag :

cat /etc/asterisk.makeopts

By: Steve Murphy (murf) 2008-09-16 15:55:10

I have a patch posted on 13467; please test it out and verify that it will
solve your problem. It's a 1.4 patch.

By: Doug (doug) 2008-09-17 00:38:07

Testing with patch from 0013490, will provide feedback.

By: Doug (doug) 2008-09-17 06:04:56

Had another crash today. added GBD debug gdb-27th-sep.txt

By: Steve Murphy (murf) 2008-09-22 10:58:07

OK, from here on out, we will ignore the first crash, and assume (perhaps, wrongly, perhaps rightly) that the patch for 13467 was effective in
solving the cdr specialized-reset problem; that the 27-sep problem
is a separate problem, involving masquerade and transfers and queues.

It may be that changes in getting the CDRs to have the right values
in transfer situations might be causing this problem; it may just as
likely be that some other problem is popping up.

So, tell me: how do we reproduce this problem? How often does it happen?
What exactly triggers it?  The more light you can shed on this problem,
the quicker we can solve it.

By: Steve Murphy (murf) 2008-09-23 11:03:26

OK, after thinking on this for a while, I've decided it will be easier to close this bug with the fix for the original problem; and that DougUDI should
open a new bug for the app_queue/masquerade/xfer 27sept crash. Otherwise, I have to completely overhaul this bug...

By: Digium Subversion (svnbot) 2008-09-23 11:32:05

Repository: asterisk
Revision: 144066

U   branches/1.4/res/res_features.c

r144066 | murf | 2008-09-23 11:32:04 -0500 (Tue, 23 Sep 2008) | 29 lines

(closes issue ASTERISK-12735)
Reported by: DougUDI
Tested by: murf

(closes issue ASTERISK-12736)
Reported by: seanbright
Tested by: murf

(closes issue ASTERISK-12717)
Reported by: edantie
Tested by: murf, edantie, DougUDI

This crash happens because we are unsafely handling old pointers.
The channel whose cdr is being handled, has been hung up and
destroyed already. I reorganized the code a bit, and tried not
to lose the fork-cdr-chain concepts of the previous code.
I now verify that the 'previous' channel (the channel we
had when the bridge was started), still exists, by looking it up
by name in the channel list. I also do not try to reset the
CDR's of channels involved in bridges.

Testing shows it solves the crash problem, and should not
negatively impact previous fixes involving CDR's generated
during/after blind transfers. (The reason we need to reset
the CDR's on the "beginning" channels in the first place).