| Summary: | ASTERISK-12735: Asterisk crash 1.4 SVN | ||
| Reporter: | Doug (doug) | Labels: | |
| Date Opened: | 2008-09-16 09:00:21 | Date Closed: | 2008-09-23 11:32:08 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Core/PBX |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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. Thanks | ||
| 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 MENUSELECT_CFLAGS=DEBUG_THREADS MALLOC_DEBUG DONT_OPTIMIZE LOADABLE_MODULES 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). ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=144066 | ||