[asterisk-bugs] [Asterisk 0017450]: [patch] "setvar" can add multiple variables with the same name to a channel, and has a mismatch between his behaviour and his do
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Jun 3 01:33:56 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17450
======================================================================
Reported By: nahuelgreco
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 17450
Category: Channels/chan_dahdi
Reproducibility: always
Severity: minor
Priority: normal
Status: new
Asterisk Version: SVN
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 267095
Request Review:
======================================================================
Date Submitted: 2010-06-02 17:28 CDT
Last Modified: 2010-06-03 01:33 CDT
======================================================================
Summary: [patch] "setvar" can add multiple variables with the
same name to a channel, and has a mismatch between his behaviour and his do
Description:
Suppose the following piece of chan_dahdi.conf:
setvar=V1=foo
channel => 1
setvar=V2=bar
channel => 2
setvar=V1=baz
channel => 3
In the current trunk version, each channel (dahdi_pvt structure) will have
his own copies of the variables (after
https://issues.asterisk.org/view.php?id=16359 fix). For example, the
ast_variables linked list for channel 3 will have the following form:
channel 3: V1=foo -> V2=bar -> V1=baz
When a call is made and dahdi_new(...) is executed, dahdi_new(...) will
processes the variables list left-to-right, so for a call in channel 3 the
value of V1 for that call will be finally "baz" because is the last one to
be set by dahdi_new(...). This makes the bug benevolous, the call variables
will be ok, but if you do a "dahdi show channel 3" you will see the two
versions of V1, and that's wrong. Before the
https://issues.asterisk.org/view.php?id=16359 fix the bug was worse,
because the call in channel 3 got V1=foo.
A patch against trunk removing the duplicates is attached.
Also, there is a conceptual mismatch. The documentation in
chan_dahdi.conf.sample states that "setvar" defines a "Channel variable to
be set for all calls from this channel". Maybe the correct behaviour is to
get only V1 defined for channel 3 and not V2, by resetting the setvar list
(confp->chan.vars) after each "channel" statement.
I also think the linked list built at confp->chan.vars is probably leaking
across reloads.
======================================================================
----------------------------------------------------------------------
(0122864) tilghman (administrator) - 2010-06-03 01:33
https://issues.asterisk.org/view.php?id=17450#c122864
----------------------------------------------------------------------
1) I agree on the leak, and I'm uploading a fix for that.
2) I don't agree on skipping variables and here's why: we have dialplan
functions which may be set with this method, and those don't have a
particular problem with being set more than once. In fact, each setting
may depend upon the previous value internally, which makes skipping
variables problematic.
3) Inheritance of previous values is a feature, not a bug. If you'd like
an explicit "clearvars" command, as we have in chan_mgcp, I'm open to that.
Issue History
Date Modified Username Field Change
======================================================================
2010-06-03 01:33 tilghman Note Added: 0122864
======================================================================
More information about the asterisk-bugs
mailing list