| Summary: | ASTERISK-11888: Queue variables are not created correctly when setXXXvar is defined for the queue. | ||
| Reporter: | Nick Barnes (bcnit) | Labels: | |
| Date Opened: | 2008-04-22 04:06:16 | Date Closed: | 2008-04-22 18:31:20 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_queue |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 12490-queuevars.diff ( 1) 12490-queuevars-2.diff ( 2) 12490-queuevars-3.diff | |
| Description: | The code: -------------------------- [macro-bridgedqueue] exten => s,1,NoOp() exten => s,n,NoOp(queuename ${QUEUENAME}) exten => s,n,NoOp(queuesrvlevel ${QUEUESRVLEVEL}) exten => s,n,NoOp(qeholdtime ${QEHOLDTIME}) exten => s,n,NoOp(qeoriginalpos ${QEORIGINALPOS}) exten => s,n,NoOp(memberinterface ${MEMBERINTERFACE}) exten => s,n,NoOp(membercalls ${MEMBERCALLS}) exten => s,n,MacroExit() --------------------------- When run from a queue defined as: --------------------------- [queuename] setinterfacevar=yes setqueuevar=yes setqueueentryvar=yes membermacro=bridgedqueue --------------------------- Gives the following output: --------------------------- -- Executing [s@macro-bridgedqueue:1] NoOp("SIP/200-084c7388", "") in new stack -- Executing [s@macro-bridgedqueue:2] NoOp("SIP/200-084c7388", "queuename TST_a|QUEUEMAX=0|QUEUESTRATEGY=ringall|QUEUECALLS=1|QUEUEHOLDTIME=0|QUEUECOMPLETED=0|QUEUEABANDONED=0|QUEUESRVLEVEL=0|QUEUESRVLEVELPERF=0.0") in new stack -- Executing [s@macro-bridgedqueue:3] NoOp("SIP/200-084c7388", "queuesrvlevel ") in new stack -- Executing [s@macro-bridgedqueue:4] NoOp("SIP/200-084c7388", "qeholdtime 5,QEORIGINALPOS=1") in new stack -- Executing [s@macro-bridgedqueue:5] NoOp("SIP/200-084c7388", "qeoriginalpos ") in new stack -- Executing [s@macro-bridgedqueue:6] NoOp("SIP/200-084c7388", "memberinterface SIP/201|MEMBERNAME=SIP/201|MEMBERCALLS=0|MEMBERLASTCALL=0|MEMBERPENALTY=1|MEMBERDYNAMIC=0|MEMBERREALTIME=1") in new stack -- Executing [s@macro-bridgedqueue:7] NoOp("SIP/200-084c7388", "membercalls ") in new stack -- Executing [s@macro-bridgedqueue:8] MacroExit("SIP/200-084c7388", "") in new stack --------------------------- i.e. all the variables created are dumped into the first one in the list as a '|' separated list. ****** ADDITIONAL INFORMATION ****** utils/extconf.c appears to contain the code for pbx_builtin_setvar which should split out this '|' separated list, but that's as far as my programming skills can take me. | ||
| Comments: | By: Nick Barnes (bcnit) 2008-04-22 05:10:08 Just noticed.... I was having a play and the line above which reads: -- Executing [s@macro-bridgedqueue:4] NoOp("SIP/200-084c7388", "qeholdtime 5,QEORIGINALPOS=1") in new stack should read: -- Executing [s@macro-bridgedqueue:4] NoOp("SIP/200-084c7388", "qeholdtime 5|QEORIGINALPOS=1") in new stack By: Jason Parker (jparker) 2008-04-22 10:56:58 This patch should fix all three cases. Please test and report back. By: Nick Barnes (bcnit) 2008-04-22 11:17:46 I applied the patch to 1.6.0b7.1 and it doesn't work - output is now: -- Executing [s@macro-bridgedqueue:1] NoOp("SIP/200-09041e00", "") in new stack -- Executing [s@macro-bridgedqueue:2] NoOp("SIP/200-09041e00", "queuename TST_A,QUEUEMAX=0,QUEUESTRATEGY=ringall,QUEUECALLS=1,QUEUEHOLDTIME=1,QUEUECOMPLETED=0,QUEUEABANDONED=0,QUEUESRVLEVEL=0,QUEUESRVLEVELPERF=0.0") in new stack -- Executing [s@macro-bridgedqueue:3] NoOp("SIP/200-09041e00", "queuesrvlevel ") in new stack -- Executing [s@macro-bridgedqueue:4] NoOp("SIP/200-09041e00", "qeholdtime 5,QEORIGINALPOS=1") in new stack -- Executing [s@macro-bridgedqueue:5] NoOp("SIP/200-09041e00", "qeoriginalpos ") in new stack -- Executing [s@macro-bridgedqueue:6] NoOp("SIP/200-09041e00", "memberinterface SIP/201,MEMBERNAME=SIP/201,MEMBERCALLS=0,MEMBERLASTCALL=0,MEMBERPENALTY=1,MEMBERDYNAMIC=0,MEMBERREALTIME=1") in new stack -- Executing [s@macro-bridgedqueue:7] NoOp("SIP/200-09041e00", "membercalls ") in new stack i.e. the "|" characters are replaced by ",". By: Jason Parker (jparker) 2008-04-22 11:59:20 The function name to set multiple variables like this also changed (I'll audit other applications, to see if this is used incorrectly anywhere else). This patch should fix that. Could you try once more? By: Nick Barnes (bcnit) 2008-04-22 12:06:06 Again, patched 1.6.0b7.1 Nope: Asterisk ended with exit status 127 Core is not dumped. By: Jason Parker (jparker) 2008-04-22 12:28:05 I can't see any reason for this code to be causing anything like that. Is this an unpatched (except for the above patch) system? By: Jason Parker (jparker) 2008-04-22 12:45:29 okay...I actually tested this third patch (using your macro)... pbx_builtin_setvar_multiple() was a static function, so app_queue wouldn't have been able to see it. I'm a little confused on how it compiled for you, but.. Today isn't my day, apparently. By: Nick Barnes (bcnit) 2008-04-22 13:04:36 Compiles cleanly, but I'm home for the night now and I won't be able to test it until tomorrow. Cheers. By: Digium Subversion (svnbot) 2008-04-22 13:09:02 Repository: asterisk Revision: 114540 U trunk/apps/app_queue.c U trunk/include/asterisk/pbx.h U trunk/main/pbx.c ------------------------------------------------------------------------ r114540 | qwell | 2008-04-22 13:09:02 -0500 (Tue, 22 Apr 2008) | 8 lines Allow setqueuevar=yes (et al) to work, after changes to pbx_builtin_setvar() (closes issue ASTERISK-11888) Reported by: bcnit Patches: 12490-queuevars-3.diff uploaded by qwell (license 4) Tested by: qwell ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=114540 By: Digium Subversion (svnbot) 2008-04-22 13:09:23 Repository: asterisk Revision: 114541 _U branches/1.6.0/ U branches/1.6.0/apps/app_queue.c U branches/1.6.0/include/asterisk/pbx.h U branches/1.6.0/main/pbx.c ------------------------------------------------------------------------ r114541 | qwell | 2008-04-22 13:09:23 -0500 (Tue, 22 Apr 2008) | 16 lines Merged revisions 114540 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r114540 | qwell | 2008-04-22 13:14:09 -0500 (Tue, 22 Apr 2008) | 8 lines Allow setqueuevar=yes (et al) to work, after changes to pbx_builtin_setvar() (closes issue ASTERISK-11888) Reported by: bcnit Patches: 12490-queuevars-3.diff uploaded by qwell (license 4) Tested by: qwell ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=114541 By: Digium Subversion (svnbot) 2008-04-22 18:31:20 Repository: asterisk Revision: 114570 _U team/seanbright/resolve-shadow-warnings/ U team/seanbright/resolve-shadow-warnings/apps/app_queue.c U team/seanbright/resolve-shadow-warnings/channels/chan_iax2.c U team/seanbright/resolve-shadow-warnings/include/asterisk/pbx.h U team/seanbright/resolve-shadow-warnings/main/channel.c U team/seanbright/resolve-shadow-warnings/main/pbx.c ------------------------------------------------------------------------ r114570 | seanbright | 2008-04-22 18:31:18 -0500 (Tue, 22 Apr 2008) | 113 lines Merged revisions 114538,114540,114543,114546,114548,114551,114553,114559 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r114538 | russell | 2008-04-22 14:04:39 -0400 (Tue, 22 Apr 2008) | 17 lines Merged revisions 114537 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r114537 | russell | 2008-04-22 13:03:33 -0500 (Tue, 22 Apr 2008) | 9 lines If the dial string passed to the call channel callback does not indicate an extension, then consider the extension on the channel before falling back to the default. (closes issue ASTERISK-11881) Reported by: darren1713 Patches: exten_dial_fix_chan_iax2.c.patch uploaded by darren1713 (license 116) ........ ................ r114540 | qwell | 2008-04-22 14:14:09 -0400 (Tue, 22 Apr 2008) | 8 lines Allow setqueuevar=yes (et al) to work, after changes to pbx_builtin_setvar() (closes issue ASTERISK-11888) Reported by: bcnit Patches: 12490-queuevars-3.diff uploaded by qwell (license 4) Tested by: qwell ................ r114543 | russell | 2008-04-22 14:30:47 -0400 (Tue, 22 Apr 2008) | 10 lines Blocked revisions 114542 via svnmerge ........ r114542 | russell | 2008-04-22 13:29:56 -0500 (Tue, 22 Apr 2008) | 3 lines After a parked call times out, allow the call back to the parker to time out. (closes issue ASTERISK-10449) ........ ................ r114546 | russell | 2008-04-22 15:45:12 -0400 (Tue, 22 Apr 2008) | 9 lines Blocked revisions 114545 via svnmerge ........ r114545 | russell | 2008-04-22 14:45:00 -0500 (Tue, 22 Apr 2008) | 2 lines Trivial change to read the number of samples from a frame before calling ast_write() ........ ................ r114548 | russell | 2008-04-22 16:25:56 -0400 (Tue, 22 Apr 2008) | 2 lines re-add a fix that got lost with a recent change ................ r114551 | russell | 2008-04-22 17:15:41 -0400 (Tue, 22 Apr 2008) | 11 lines Blocked revisions 114550 via svnmerge ........ r114550 | russell | 2008-04-22 16:14:55 -0500 (Tue, 22 Apr 2008) | 4 lines I thought I was going to be able to leave 1.4 alone, but that was not the case. I ran into some problems with G.722 in 1.4, so I have merged in all of the fixes in this area that I have made in trunk/1.6.0, and things are happy again. ........ ................ r114553 | murf | 2008-04-22 17:57:57 -0400 (Tue, 22 Apr 2008) | 14 lines (closes issue ASTERISK-11872) Reported by: triccyx I had a bit a problem reproducing this in my setup (trying not to disturb my other stuff) but finally, I got it. The problem appears to be that the extension is being added in replace mode, which kinda assumes that the pattern trie has been formed, when in fact, in this case, it was not. The checks being done are not nec. when the tree is not yet formed, as changes like this will be summarized when the trie is formed in the future. I tested the fix, and the crash no longer happens. Feel free to open the bug again if this fix doesn't cure the problem. ................ r114559 | russell | 2008-04-22 18:17:31 -0400 (Tue, 22 Apr 2008) | 13 lines Merged revisions 114558 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r114558 | russell | 2008-04-22 17:15:36 -0500 (Tue, 22 Apr 2008) | 5 lines When we receive a full frame that is supposed to contain our call number, ensure that it has the correct one. (closes issue ASTERISK-9772) (AST-2008-006) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=114570 | ||