[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:                     acknowledged
Asterisk Version:           1.6.1.6 
JIRA:                       SWP-1414 
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-06-07 13:03 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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0017430 segfault in for loop embedded switch st...
====================================================================== 

---------------------------------------------------------------------- 
 (0123073) murf (manager) - 2010-06-07 13:03
 https://issues.asterisk.org/view.php?id=16053#c123073 
---------------------------------------------------------------------- 
OK, I think lmadsen could be correct, and I think I've seen this to, on
reloads.
Perhaps, a reload is a little more demanding of memory capacity than a
normal start.

You have some options here. 

First option:  Is it really a memory issue? Remember that Asterisk is
heavily threaded. Also remember that each thread is allocated a certain
amount of stack space. You can tweek this amount when you compile
Asterisk.

In utils/utils.c (and asterisk/utils.h) the thread stacksize is set to
240K for 32 bit machines (512K for 64bit machines). If you change the
definition in utils.h, and recompile, every thread will take up more stack
space.

As long as you don't max out total stack allocation, you'll be OK. Double
it and see if this solves the problem.



Option 2. 

You know, you don't have to recompile your extensions.ael file every time
you fire up asterisk. You can compile it into extensions.conf format, and
just
include that in your normal extensions.conf file. Use "aelparse -d -w"
while parked in the same dir as your extensions.ael file. A file called
"extensions.conf.aeldump" will be created. If you put a #include
extensions.conf.aeldump in your extensions.conf file, then the end affect
is the same as starting up with the extensions.ael being present. Make sure
to move/remove the extensions.ael file before starting asterisk.

The advantage of option https://issues.asterisk.org/view.php?id=2 is that the
ael compiler is run outside
asterisk and not limited by the thread stack size.

So, experiment and see if the stack size is the problem. Or, if the AEL
compiler embedded in Asterisk isn't working in the thin slice of stack
available to it, run the standalone. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-07 13:03 murf           Note Added: 0123073                          
======================================================================