[asterisk-bugs] [JIRA] (ASTERISK-17799) AEL reload causes loss of control in a macro

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-17799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246886#comment-246886 ] 

Friendly Automation commented on ASTERISK-17799:
------------------------------------------------

Change 11270 merged by George Joseph:
res_ael: Create consistent label names across reloads

[https://gerrit.asterisk.org/c/asterisk/+/11270|https://gerrit.asterisk.org/c/asterisk/+/11270]

> AEL reload causes loss of control in a macro
> --------------------------------------------
>
>                 Key: ASTERISK-17799
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17799
>             Project: Asterisk
>          Issue Type: Bug
>          Components: PBX/pbx_ael
>            Reporter: Kirill Katsnelson
>            Severity: Minor
>
> Reloading AEL while calls are in progress causes a lossage with the following warning:
> [2011-05-04 21:15:54.465] WARNING[36701]: pbx.c:4812 __ast_pbx_run: Channel 'SIP/250-00000022' sent into invalid extension 'sw_4117_foo' in context 'reload-bug', but no invalid 
> handler
> ****** STEPS TO REPRODUCE ******
> You'll need a way to start a call, e. g. a SIP device sending into the context from-sip.
> AEL:
> context from-sip {
>   777 => {
>    Verbose(1,Run ael reload quickly now!);
>    &reload-bug(foo);
>  }
> }
> macro reload-bug(x) {
>   switch(${x}) {
>     default:
>       Wait(5);
>       Verbose(1,Either you did not or the bug was fixed.);
>   }
> }
> 1. Reload this AEL
> 2. Send a call to ext. 777
> 3. Reload AEL again when you see the verbose message
> 4. Wait up to 5 seconds.
> The warning is printed, and the call is lost. The second verbose message is never printed.
> ****** ADDITIONAL INFORMATION ******
> Note that extension patterns within generated macros contain an integer number that changes with every reload of AEL. Even if AEL script did not change, the numbers do, and this is what is causing the bug.
> pbx6*CLI> dialplan show reload-bug
> [ Context 'reload-bug' created by 'pbx_ael' ]
>   'sw_4203_' =>     10. Goto(sw_4203_.,10)                        [pbx_ael]
>   '~~s~~' =>        1. MSet(LOCAL(x)=${ARG1})                     [pbx_ael]
>                     2. MSet(LOCAL(~~EXTEN~~)=${EXTEN})            [pbx_ael]
>                     3. MSet(LOCAL(~~EXTEN~~)=${~~EXTEN~~})        [pbx_ael]
>                     4. Goto(sw_4203_${x},10)                      [pbx_ael]
>                     5. NoOp(Finish switch_reload-bug_4203)        [pbx_ael]
>                     6. Return()                                   [pbx_ael]
>   '_sw_4203_.' =>   10. Wait(5)                                   [pbx_ael]
>                     11. Verbose(1,Either you did not or the bug was fixed.) [pbx_ael]
>                     12. Goto(~~s~~,5)                             [pbx_ael]
> -= 3 extensions (10 priorities) in 1 context. =-
> pbx6*CLI> ael reload
> [2011-05-04 21:27:12.233] NOTICE[27338]: pbx_ael.c:122 pbx_load_module: Starting AEL load process.
> ....
> pbx6*CLI> dialplan show reload-bug
> [ Context 'reload-bug' created by 'pbx_ael' ]
>   'sw_4289_' =>     10. Goto(sw_4289_.,10)                        [pbx_ael]
>   '~~s~~' =>        1. MSet(LOCAL(x)=${ARG1})                     [pbx_ael]
>                     2. MSet(LOCAL(~~EXTEN~~)=${EXTEN})            [pbx_ael]
>                     3. MSet(LOCAL(~~EXTEN~~)=${~~EXTEN~~})        [pbx_ael]
>                     4. Goto(sw_4289_${x},10)                      [pbx_ael]
>                     5. NoOp(Finish switch_reload-bug_4289)        [pbx_ael]
>                     6. Return()                                   [pbx_ael]
>   '_sw_4289_.' =>   10. Wait(5)                                   [pbx_ael]
>                     11. Verbose(1,Either you did not or the bug was fixed.) [pbx_ael]
>                     12. Goto(~~s~~,5)                             [pbx_ael]
> -= 3 extensions (10 priorities) in 1 context. =-
> Maybe basing the numbers off actual macro code (e. g., hashes) would be a better option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)