[asterisk-bugs] [Asterisk 0016053]: Crash on deeply nested while/if statements in AEL

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16053 
====================================================================== 
Reported By:                diLLec
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16053
Category:                   PBX/pbx_ael
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.1.6 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-10-11 17:49 CDT
Last Modified:              2010-05-04 17:39 CDT
====================================================================== 
Summary:                    Crash on deeply nested while/if statements in AEL
Description: 
While reloading ael via ael reload the asterisk process runs into SIGSEGV.


This bug is curios since Asterisk starts and loads the ael very well. Also
if ael reload is typed in at the cli when starting Asterisk with -c is
working fine.

The issue only shows up when using asterisk manager or asterisk -r.
====================================================================== 

---------------------------------------------------------------------- 
 (0121382) diLLec (reporter) - 2010-05-04 17:39
 https://issues.asterisk.org/view.php?id=16053#c121382 
---------------------------------------------------------------------- 
you're right. Actually I've figured something out while trying to get a
valid stacktrace: 

The uname I've pasted earlier is, as mentioned, from a VM which is
installed as a x64 system. Anyway the RPM packages I've used to install
asterisk were built on a i686 machine. 

I've then tried to compile asterisk with DONT_OPTIMIZE on the x64 system
and got no problem while reloading the dialplan. So, it seams to be a 32bit
problem. 

To verify that I've started to compile (in turn with DONT_OPTIMIZE) on the
32bit system where the RPM packages are built and after install tried to
load the dialplan there. The result was that I'm now able to load up to a
depth of 14 but still got the same issue when I try to use a depth of 15. 

I've created a BT/BT Full on that and attached it:
extensions.ael-2010-05-04_depth13-backtrace_no-optimize

The uname of the system is:

2.6.18-128.2.1.el5PAE

free says:

# free -m
             total       used       free     shared    buffers     cached
Mem:          4051       1134       2916          0        200        739
-/+ buffers/cache:        194       3856
Swap:         1983          0       1983

cpuinfo:
# cat /proc/cpuinfo  | grep "model name"
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz
model name      : Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-04 17:39 diLLec         Note Added: 0121382                          
======================================================================