[asterisk-bugs] [Asterisk 0017450]: [patch] "setvar" can add multiple variables with the same name to a channel
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Apr 12 13:12:31 CDT 2011
The following issue has been RESOLVED.
======================================================================
https://issues.asterisk.org/view.php?id=17450
======================================================================
Reported By: nahuelgreco
Assigned To: jrose
======================================================================
Project: Asterisk
Issue ID: 17450
Category: Channels/chan_dahdi
Reproducibility: always
Severity: minor
Priority: normal
Status: resolved
Asterisk Version: SVN
JIRA: SWP-1635
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 267095
Request Review:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2010-06-02 17:28 CDT
Last Modified: 2011-04-12 13:12 CDT
======================================================================
Summary: [patch] "setvar" can add multiple variables with the
same name to a channel
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.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2011-04-12 13:12 svnbot Status ready for testing =>
assigned
2011-04-12 13:12 svnbot Assigned To => jrose
2011-04-12 13:12 svnbot Status assigned => resolved
2011-04-12 13:12 svnbot Resolution open => fixed
======================================================================
More information about the asterisk-bugs
mailing list