[Home]

Summary:ASTERISK-12951: after return from child context ARG is cleared
Reporter:pj (pj)Labels:
Date Opened:2008-10-22 15:10:38Date Closed:2011-06-07 14:07:45
Priority:MinorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:simple ael dialplan, that ilustrates situation:
after gosub to child and return back to parent context, ARG1 value is cleared after return back to parent context.
tested svn trunk and svn branch 1.6.0 both have this issue.


context parent {
 s => {
       Verbose(In parent before gosub to child cx arg1 has value ${ARG1});
       Gosub(child,s,1(${ARG1}));
       Verbose(In parent after gosub to child cx arg1 has value ${ARG1});
       return;
 }
}

context child {
 s => {
       Verbose(In child arg1 has value ${ARG1});
       return;
 }
}


****** ADDITIONAL INFORMATION ******

[Oct 22 22:13:23]     -- Executing [959@testservices:3] Gosub("SIP/324-b7334e18", "parent,s,1(324)") in new stack
[Oct 22 22:13:23]     -- Executing [s@parent:1] Verbose("SIP/324-b7334e18", "In parent before gosub to child cx arg1 has value 324") in new stack
[Oct 22 22:13:23] In parent before gosub to child cx arg1 has value 324
[Oct 22 22:13:23]     -- Executing [s@parent:2] Gosub("SIP/324-b7334e18", "child,s,1(324)") in new stack
[Oct 22 22:13:23]     -- Executing [s@child:1] Verbose("SIP/324-b7334e18", "In child arg1 has value 324") in new stack
[Oct 22 22:13:23] In child arg1 has value 324
[Oct 22 22:13:23]     -- Executing [s@child:2] Return("SIP/324-b7334e18", "") in new stack
[Oct 22 22:13:23]     -- Executing [s@parent:3] Verbose("SIP/324-b7334e18", "In parent after gosub to child cx arg1 has value ") in new stack
[Oct 22 22:13:23] In parent after gosub to child cx arg1 has value
[Oct 22 22:13:23]     -- Executing [s@parent:4] Return("SIP/324-b7334e18", "") in new stack
Comments:By: Leif Madsen (lmadsen) 2008-10-22 15:15:56

I am imagining this is happing in dialplan logic as well, and not just AEL. Can someone confirm that? If that is the case, this might be better for Corydon76 to look at.
By: pj (pj) 2008-10-22 15:20:59

also notice, that if I gosub to child without passing argument to child context, ie. Gosub(child,s,1);
ARG1 value is retained in both parent and child.
it's correct, that ARG1 in child have value, even if no argument is passed when gosub to child? imho, ARG1 should be empty in this case.

[Oct 22 22:25:46]     -- Executing [959@testservices:3] Gosub("SIP/324-b7334e18", "parent,s,1(324)") in new stack
[Oct 22 22:25:46]     -- Executing [s@parent:1] Verbose("SIP/324-b7334e18", "In parent before gosub to child cx arg1 has value 324") in new stack
[Oct 22 22:25:46] In parent before gosub to child cx arg1 has value 324
[Oct 22 22:25:46]     -- Executing [s@parent:2] Gosub("SIP/324-b7334e18", "child,s,1") in new stack
[Oct 22 22:25:46]     -- Executing [s@child:1] Verbose("SIP/324-b7334e18", "In child arg1 has value 324") in new stack
[Oct 22 22:25:46] In child arg1 has value 324
[Oct 22 22:25:46]     -- Executing [s@child:2] Return("SIP/324-b7334e18", "") in new stack
[Oct 22 22:25:46]     -- Executing [s@parent:3] Verbose("SIP/324-b7334e18", "In parent after gosub to child cx arg1 has value 324") in new stack
[Oct 22 22:25:46] In parent after gosub to child cx arg1 has value 324
[Oct 22 22:25:46]     -- Executing [s@parent:4] Return("SIP/324-b7334e18", "") in new stack
By: Steve Murphy (murf) 2008-10-24 14:57:30

I've given this some thought; The fact that args are erased is an artifact of
gosub processing. I don't think you can call this a bug -- all languages
have undocumented (gray) areas in their specs, and you do well not to
use undocumented features, because they can change behavior at any time, and you will not have anyone to blame but yourself.

If you are using AEL, do not use the Gosub app. Use the macro keyword and constructs instead. Do NOT use temporary variables outside their normal scope, nor depend on their current behavior outside that scope. In AEL, never use $(ARGx}, neither in a macro or outside of one. That way, you can take advantage of the upwards compatibility that AEL will provide.

Even if you are using extensions.conf, you should not play with or depend on the value of ${ARGx} variables outside the Macro or Gosub context. The behavior is undocumented, and guaranteed to change over time. It is bad programming practice to play tricks with such items.

Treat ${ARGx} items as temporary in Gosubs/Macros, as well as named arguments in AEL. Access only the ones passed.  To do otherwise would only introduce
bugs as time goes on.

If you feel strongly that I'm missing some important point, let me know-- just reopen this and we'll work it out.