Summary:	ASTERISK-11516: Segmentation Fault when Calling app Voicemail after Blind Transfer
Reporter:	darrylc (darrylc)	Labels:
Date Opened:	2008-02-26 09:55:36.000-0600	Date Closed:	2008-10-05 16:47:28
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) bt_full.txt ( 1) bt.txt ( 2) threads.txt
Description:	So I have a macro called macro-staff which is used to handle extension to extension dialing.  The macro works perfectly for everything except BLIND call transfers.  In features.conf the blind transfer key is set to '##' so if you press '##' during a call Asterisk will prompt you for the extension you wish to blind transfer the call to. Here is the situation.  The transfer actually works, so when you press '##100#' as an example the call is properly transfered to extension 100.  The problem is if extensions 100 does not answer, macro-staff tries to send the call into Voicemail(100) and as soon as that happens Asterisk does a Segmentation fault. Interestingly enough if you do a transfer from the phone, using the Transfer button on the acutal phone, and extension 100 does not answer, and VoiceMail(100) is called from inside macro-staff, there is NO segmentation fault.  It only does a segmentation fault when it reaches voicemail from a blind transfer using the '##'. macro-staff runs no matter what, so if you press '##' to do a blind transfer, macro-staff is called (nested) just the same as it would be if you transfer the call using the transfer button on the phone.  So either way there is a nested call to macro-staff, but only one when using the '##', (blind transfer) does a segmentation fault happen. ****** STEPS TO REPRODUCE ****** Please a call from extension 101 to extension 106 using your macro-staff, the phone will ring and voicemail will work as expected. Now again place a call from extension 101 to extension 106, but this time have extension 106 do a blind transfer to extension 100 (On key pad of x106 we dial '##100#'), you will see extension 100 rings as expected.  Don't answer extension 100, let it go to Voicemail.  As soon as Voicemail(100) is called Asterisk will die with a segmentation fault. If you do this exact same thing but don't use Blind Transfer Asterisk does not die with segmentation fault.   Example: Place a call from extension 101 to extension 106, but this time have extension 106 transfer the call to extension 100 using the SIP Phones TRANSFER BUTTON, you will see extension 100 rings as expected.  Don't answer extension 100, let it go to Voicemail, this time Voicemail works as expected with no segmentation fault. The segmentation fault only happens with a Blind Transfer. ****** ADDITIONAL INFORMATION ****** Am using realtime odbc for voicemail.
Comments:	By: darrylc (darrylc) 2008-02-26 10:00:00.000-0600 Something went strange in the formatting of the message above, the blind transfer key sequence is # # 100 #, not sure why the formatting went like that in the original bug report. By: Tilghman Lesher (tilghman) 2008-02-26 10:09:56.000-0600 Please report this issue upstream to the PsqlODBC project, as it is crashing deep within that library. Not an Asterisk bug. By: darrylc (darrylc) 2008-02-26 10:12:58.000-0600 Corydon76: I am trying to get a grasp on this, if its an issue with something else why does it only Seg Fault on blind transfers and not every type of transfer? Thanks in advance. By: Jason Parker (jparker) 2008-02-26 12:19:38.000-0600 Just a guess, but are any of the working voicemail boxes using numeric contexts?  I see in this specific case, context is "4169173818".  Seems a little unusual, and I could see the database doing the wrong thing. By: darrylc (darrylc) 2008-02-26 12:27:25.000-0600 Hi Qwell. The extensions are set as DID_Mailbox.  So example 4169173818_100, 4169173818_101, 4169173818_106.  Its to keep the extensions separate for the different numbers on the system, and also to allow the reuse of extensions. Everything works perfectly, there is no issue with leaving voicemail or anything like that.  If you call in and leave voicemail, or dial extension to extension voicemail works perfectly. The only time there is a problem is if you do a blind transfer.  Thats when Asterisk does a seg fault.  Other than that voicemail works perfect and Asterisk never crashes. By: Jason Parker (jparker) 2008-02-26 12:35:07.000-0600 4169173818_100 is alphanumeric.  4169173818 is not.  You should find out why that's behaving differently. By: darrylc (darrylc) 2008-02-26 12:39:17.000-0600 Qwell, I am not sure I follow you...  Those are just the extensions... The voicemail is handled in the database in which case the mail boxes are "not" alpha numeric.  In the database the mailboxes would be defined as 100,101,106 under the context of 4169173818. There are no alpha numeric mailboxes.... By: darrylc (darrylc) 2008-03-20 11:28:40 Hi Guys Just wondering if there is any updates with this one, or any chance of getting fixed before the next release?  Would hate to have to disable blind transfers in production to avoid segfaulting Asterisk. Cheers! By: Jason Parker (jparker) 2008-04-25 17:41:09 We would need to see an unoptimized backtrace here before we would be able to do anything.  It appears to show an impossible situation (i = 5, numfields = 0). See doc/backtrace.txt By: darrylc (darrylc) 2008-04-28 18:38:34 Just to clarify the attached (bt.txt, bt_full.txt) are not what you need? Are they "optimized"?  If so perhaps thats the default install behavior for Asterisk, but either way I want to confirm this before I recompile Asterisk and do the "bt" files again.   If you can please clarify this I will be sure to get you guys over the requested information. Cheers! By: snuffy (snuffy) 2008-04-30 18:12:20 Yes by default its set to optimised. To not optimise  do the following > make menuselect Under 'compiler flags - development' make sure the 'DONT_OPTIMIZE' is set then recompile and if the same error occurs post another set of files like u've done above By: darrylc (darrylc) 2008-05-07 08:36:01 Thanks for the clarification snuffy For some reason when I recompiled Asterisk with 'DONT_OPTIMIZE' its no longer crashing on blind transfers.  This does not make sense and I am trying to figure out why this is, and also how to reproduce the seg fault. If it will not crash like this I will re-compile back the way I had it before and see if the symptoms return. Thanks again for your follow-up and clarification. Cheers! By: Tilghman Lesher (tilghman) 2008-05-13 15:02:37 This tends to point towards possibly a gcc bug. By: darrylc (darrylc) 2008-05-13 19:05:27 Hi Corydon76, I am still running with 'DONT_OPTIMIZE' enabled as I have been trying to reproduce the segmentation fault.  If by early next week I still have not been able to reproduce this I am going to compile back to the way it was before and check again if the segmentation fault returns. If it does at least its a step in the right direction and we may be on the way to squashing this bug.  Thanks again for your follow up. Cheers! By: Joshua C. Colp (jcolp) 2008-05-28 11:28:53 darrylc: It has been 2 weeks, any update? By: darrylc (darrylc) 2008-05-29 09:47:43 My apologies for not doing this last week as was my intent.  I got caught up with other projects so sorry about that. Ok so looks like this bug is confirmed now.  I compiled back Asterisk to the way it was before with 'DONT_OPTIMIZE' disabled and the problem is happening again (Segmentation Faults on Blind Transfers). Every time I do a blind transfer Asterisk seg faults.  So looks like Corydon76 may have been onto something when he suggested it may be some sort of gcc bug. So this message is just to confirm that if I compile with 'DONT_OPTIMIZE' 'enabled' the segmentation fault does not happen, but if I compile with 'DONT_OPTIMIZE' 'disabled' then the segmentation fault happens everytime I do a blind transfer. Hope this helps and please do let me know if you need any clarification. Cheers! By: Tilghman Lesher (tilghman) 2008-08-01 12:05:47 You might try running this under valgrind (as specified in doc/valgrind.txt) to get more information on what specific operation is making it crash. By: Tilghman Lesher (tilghman) 2008-09-11 17:41:02 darrylc: have you been able to run this under valgrind yet?  Even if it doesn't crash under valgrind, the output may still help us diagnose what the issue really is. By: darrylc (darrylc) 2008-09-14 09:54:56 Corydon76 for some reason I was not notified of your post on 2008-08-01, I will try to do this ASAP and post back my findings. By: darrylc (darrylc) 2008-09-16 09:56:05 Hi Corydon76 Ok as requested attached are the files you wanted. [ http://72.249.84.171/valgrind.zip ] Please let me know if you require any further information. By: Russell Bryant (russell) 2008-10-05 16:47:23 I agree with Corydon76 here.  The crash is clearly down in the postgres odbc driver.  There is nothing we can do.