Summary:	ASTERISK-14432: [patch] It crashes often daily and always in the same function
Reporter:	Private Name (falves11)	Labels:
Date Opened:	2009-07-08 03:09:35	Date Closed:	2010-06-07 09:30:15
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) crash_17.txt ( 1) crash1.rtf ( 2) crash1.txt ( 3) crash-14.txt ( 4) crash2.txt ( 5) crash3.txt ( 6) rtp.patch
Description:	I am uploading 3 GDB trace (bt full)
Comments:	By: Private Name (falves11) 2009-07-08 17:53:28 The file crash1.rtf was originated with revision  SVN-branch-1.6.2-r204951. It shows the same function blowing up. By: Private Name (falves11) 2009-07-27 06:53:51 should I apply the patch and test it or wait until it goes into the SVN? Or unless I test it it will not go to the mainstream? By: Private Name (falves11) 2009-07-27 08:21:31 Question: how do I tell the Asterisk installer to automatically set "don't optimize" and other two options without manually going into "make menuslect"? By: Mark Michelson (mmichelson) 2009-07-27 09:22:24 I'm marking this issue private since there are security implications here. Falves11, please try the patch fnordian uploaded. It should prevent your crashes. Um, okay, so I apparently made this note private, but I'm trying to mark the issue private. I'll try again. By: Mark Michelson (mmichelson) 2009-07-27 09:23:39 I'm marking this issue private since it has security implications to it. Falves11, please apply fnordian's patch. It should prevent your crashes from occurring. By: Private Name (falves11) 2009-07-28 15:14:35 I keeps crashing. I just uploaded a trace. Pleas advise. By: Mark Michelson (mmichelson) 2009-07-28 16:59:20 The newest trace you provided is definitely a different crash and appears to be due to one channel offering T.38 to a channel that does not have support for T.38. By: Private Name (falves11) 2009-07-28 17:03:19 The question is if should it crash under those circumstances or do whatever it needs to do to ignore T.38. But regarding the orihinal issue, please include it in the main 1.6X version. It definitely works fine. By: Mark Michelson (mmichelson) 2009-07-28 17:06:32 It definitely should *not* crash. I have an idea for a potential fix, but I'm not sure if it is complete enough. I have asked the developer who has been doing the most work with T.38 code lately to take a look at this. By: Private Name (falves11) 2009-08-01 18:02:35 I am back to using version 1.4. I wonder if this issue and the rtp.c patch is applicable to 1.4 and if the T.38 crash will affect also 1.4. By: Mark Michelson (mmichelson) 2009-08-03 09:09:58 Neither crash affects 1.4. 1.4 doesn't have support for RTP text payloads, and it doesn't have the same method of handling T.38 that the 1.6 branches do, so neither crash will happen with 1.4. Btw, the rtp crash has been fixed in all 1.6 branches at this point. I'm sending a reminder to our resident T.38 person to see if he has an opinion on how to fix the T.38 crash. By: Matthew Nicholson (mnicholson) 2010-06-03 14:27:35 Looking at the T.38 crash (crash17.txt), it does not look like this crash could happen in the latest 1.6.2 or trunk code unless there is some sort of race condition present, which at a quick glance, there does not appear to be.  What version/svn revision of asterisk is the crash17.txt bt from? By: Private Name (falves11) 2010-06-03 14:34:33 I was told that since I cannot provide debugs or use Valgrind, my bugs will not be considered, so I had to downgrade my company asterisk 1.4, and erase all instances of 1.6.X. It still crashes, it did this morning, and I am uploading here the new 1.4 crash. What makes me wonder is why do we even capture crashes using GDB if the traces are useless to indicate what goes wrong. Some developers, I have seen, can look at a trace and figure out what is wrong, though. By: Matthew Nicholson (mnicholson) 2010-06-03 14:45:54 Please open a new bug for this new crash, it does not appear to be related to the two crashes discussed here previously.  At times a GDB backtrace is not enough to determine what the root cause of the crash is; sometimes it is enough. By: Matthew Nicholson (mnicholson) 2010-06-07 09:30:15 I am closing this, as it appears the original crash was fixed.  New bugs should be opened for additional crashes.