Summary:	ASTERISK-09206: Calling VoiceMailMain within a macro with an SLA-style setup crashes asterisk
Reporter:	dtyoo (dtyoo)	Labels:
Date Opened:	2007-04-05 18:40:11	Date Closed:	2007-06-19 16:11:49
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Applications/SLA
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 9482-gdb-output.txt
Description:	I have a test environment with an SLA setup that closely mirrors what is described in the shared line appearances document (sla.pdf).  It is a 2 station, 2 line setup using sip trunks (no zap channels).  What I am finding is that when I call into voicemail (VoiceMailMain) it will always crash the server within 5 calls.  It doesn't always crash the server on the first call, but very reliably if you try up to 5 times.  This only happens when the call to VoiceMailMain is performed from within a macro. I realize that this may not be a bug with SLA itself, but it is definitely only happening with my SLA setup, and I thought it was worthwhile reporting it. Here are my configurations: sla.conf [line1] type=trunk device=Local/disa@line1_outbound autocontext=line1 [line2] type=trunk device=Local/disa@line2_outbound autocontext=line2 [station1] type=station device=SIP/station1 trunk=line1 trunk=line2 autocontext=sla_stations [station2] type=station device=SIP/station2 trunk=line1 trunk=line2 autocontext=sla_stations extensions.conf [line1] exten => s,1,SLATrunk(line1) [line2] exten => s,1,SLATrunk(line2) [line1_outbound] exten => disa,1,Disa(no-password|line1_outbound) include => mycontext [line2_outbound] exten => disa,1,Disa(no-password|line2_outbound) include => mycontext [sla_stations] exten => station1,1,SLAStation(station1) exten => station1_line1,hint,SLA:station1_line1 exten => station1_line1,1,SLAStation(station1_line1) exten => station1_line2,hint,SLA:station1_line2 exten => station1_line2,1,SLAStation(station1_line2) exten => station2,1,SLAStation(station2) exten => station2_line1,hint,SLA:station2_line1 exten => station2_line1,1,SLAStation(station2_line1) exten => station2_line2,hint,SLA:station2_line2 exten => station2_line2,1,SLAStation(station2_line2) [mycontext] exten => 1111,1,Macro(test) [macro-test] exten => s,1,VoiceMailMain(@test) sip.conf [station1] accountcode=xxxxxxxxxx type=friend host=dynamic context=sla_stations subscribecontext=sla_stations md5secret=xxxxxx callerid="xxxx" <xxx-xxx-xxxx> mailbox=xxxxxxxxxx@xxxxxxxxxxx nat=yes qualify=yes canreinvite=no [station2] accountcode=xxxxxxxxxx type=friend host=dynamic context=sla_stations subscribecontext=sla_stations md5secret=xxxxxx callerid="xxxx" <xxx-xxx-xxxx> mailbox=xxxxxxxxxx@xxxxxxxxxxx nat=yes qualify=yes canreinvite=no If I dial "1111" from Line 1 on either phone it always crashes within a few tries. I am happy to provide any further information or do any further testing to help clarify this issue. ****** ADDITIONAL INFORMATION ****** Asterisk 1.4.2, CentOS 4.4, 2 x Polycom 501 handsets
Comments:	By: Russell Bryant (russell) 2007-04-09 14:09:40 Can you please get a backtrace of the crash?  Here is how to do so ... 1) Build asterisk with DONT_OPTIMIZE enabled.  Run "make menuselect", go down to "Compiler Flags", select DONT_OPTIMIZE, and hit 'x' to save and quit.  Run "make" and "make install" again. 2) Start Asterisk with the -g option.  For example, asterisk -vvvvgc 3) When the crash occurs, it should leave a core file that looks something like core.12345. 4) Use gdb to get the back trace using the following commands: $ gdb /usr/sbin/asterisk core.12345 (gdb) bt (gdb) bt full Then, attach the gdb output to this bug report. Thanks! By: dtyoo (dtyoo) 2007-04-09 18:31:45 Thanks for the clear instructions.  I followed your steps.  However, the crash is not re-producible when asterisk is compiled with the DONT_OPTIMIZE flag enabled.  If I disable this flag, re-make, re-make install, the crash becomes re-producible again.  I've switched back and forth testing this several times now so I don't think I am doing anything wrong.  Is there any other approach or information that could help track this down? By: Russell Bryant (russell) 2007-04-09 23:45:44 Wow, that is certainly odd.  However, it would not be the first time I have seen it happen!  :) How about try to generate a backtrace from the core dump that gets generated with optimizations turned on.  There is still a chance it could be useful. By: dtyoo (dtyoo) 2007-04-10 09:40:57 I've uploaded the gdb output from a core file produced with the optimizations turned on. By: Russell Bryant (russell) 2007-04-10 10:40:05 Thanks for the update.  Unfortunately, the output is pretty useless.  I will attempt to reproduce the problem here. By: Russell Bryant (russell) 2007-06-19 16:11:48 I can't reproduce this issue.  If you are still able to reproduce it using the latest version, then feel free to reopen this bug and I'll keep going at trying to track it down.  Thanks!