Summary:	ASTERISK-09788: "Maximum PBX stack exceeded" raised by including more than AST_PBX_MAX_STACK *not nested* contexts
Reporter:	alexb (alexb)	Labels:
Date Opened:	2007-07-02 04:54:54	Date Closed:	2011-06-07 14:07:46
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	PBX/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) extensions.conf ( 1) sip.conf
Description:	Including more than 127 contexts causes Jul  2 11:16:22 WARNING[5561] pbx.c: Maximum PBX stack exceeded Please note they are not nested, but just included in one single context. The value depends by AST_PBX_MAX_STACK, which is set to 128. Anyway this is supposed to be the maximum depth, not the number of includes. This behaviour has already been pointed out on the dev mailing list: http://lists.digium.com/pipermail/asterisk-dev/2007-June/028164.html There are also other threads opened, but unfortunately the discussion was not fed by any developer. However this is a bug and plain Asterisk files to reproduce it are attached.
Comments:	By: Tilghman Lesher (tilghman) 2007-07-02 10:33:30 Seems rather contrived.  Wouldn't it be easier simply to use contexts as classes of extensions, rather than to assign one extension to each context? By: alexb (alexb) 2007-07-02 10:52:38 IMHO it's not relevant what I include - i.e. contexts could be applications rather than extensions. ;) The matter of fact is that including more than 128 (=AST_PBX_MAX_STACK) contexts leads Asterisk to that WARNING, which is a bug since  AST_PBX_MAX_STACK is the maximum depth, not the maximum number of includes allowed. Please note that if the application/extension/whatever else is included beyond the 128th position, the call fails. By: Tilghman Lesher (tilghman) 2007-07-02 11:28:03 Actually, no, it is the maximum number of includes.  I was wrong in my initial assessment on the mailing list. By: alexb (alexb) 2007-07-02 11:46:55 OK, given it's not a bug this report should be closed. Anyway do you think it may be increased w/o affecting performances, please? I think so, however an answer from a developer here or on the mailing list would be really appreciated. :) Thanks in advance! By: Tilghman Lesher (tilghman) 2007-07-02 11:56:37 Increasing it will certainly affect a measure of performance, as this is a sequentially searched list and as you increase the number of items in it, so the time necessary to run the dialplan will increase linearly. At some point, it may be changed to use a hashtable lookup, which should change its lookup time from O(n) to O(1), which would be a vast improvement.  That code, however, is not yet written, so it's a long way off. By: Tilghman Lesher (tilghman) 2007-07-02 11:57:33 Closed by request of reporter.