Summary:ASTERISK-15202: Recursion crash in pbx_ael.c
Reporter:Daniel Ferrer (dferrer)Labels:
Date Opened:2009-11-23 08:11:45.000-0600Date Closed:2010-12-23 18:51:59.000-0600
Versions:Frequency of
Environment:Attachments:( 0) bt.txt
( 1) extensions.ael
Description:Attached extensions.ael makes asterisk crash on an 'ael reload'. Only crashes for recursion >= 7, if delete 1 recursion step it doesn't crash. Something about this is mentioned in http://www.voip-info.org/wiki/view/Asterisk+AEL2:
"Macros have a serious limitation, in that one cannot recursively nest macro calls deeper than 7 levels, due to limitations on thread stack allocation sizes."

The insteresting thing is that only it crashes if attach via 'asterisk -r' and do 'ael reload'. If I run within a console 'asterisk -vvvc' (or in tty9 if ran from asterisk init script) it doesn't crash, only crash if in another tty I attach to asterisk process via asterisk -r. Because of that, if I use /etc/init.d/asterisk script, pbx_ael.so gets loaded an compiled at startup, when asterisk loads all its modules, but when I want to reload AEL it crashes.

Attached bt and AEL code. If this is a thread stack allocation restriction, I suggest to limit if-recursion to 7 levels, avoiding asterisk crashes for "malformed" AEL code.


Crash doesn't occur on x86_64 arch, only on i386 (tested only on CentOS 5 on i386 an x86_64 archs).
Comments:By: Tilghman Lesher (tilghman) 2010-12-23 18:51:59.000-0600

Unfortunately, there's no real fix for this, because as you correctly pointed out, this is a problem inherent in the Macro application.  Some uses will crash Asterisk at 7 levels deep (such as AEL), while others can go to 12 levels deep without problems.  The real solution is to upgrade to 1.6.2 or 1.8, where subroutines have been changed to use Gosub, which does not have this problem.  You can solve this for yourself by changing the amount of stack allocated per thread in include/asterisk/utils.h (AST_STACKSIZE is the define).