[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:30 CDT 2011
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: ready for testing
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:
======================================================================
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.
======================================================================
----------------------------------------------------------------------
(0133665) svnbot (reporter) - 2011-04-12 13:12
https://issues.asterisk.org/view.php?id=17450#c133665
----------------------------------------------------------------------
Repository: asterisk
Revision: 313432
U branches/1.6.2/channels/chan_dahdi.c
------------------------------------------------------------------------
r313432 | jrose | 2011-04-12 13:12:29 -0500 (Tue, 12 Apr 2011) | 14 lines
fixes a chan_dahdi reload memory leak that occurs when there are channel
variables
reload chan_dahdi would cause variables to spill over from the previous
config into the current config as
well as add any variables in the new config (if left the same, full on
duplication) This patch purges variables
from pvts when they are reconfigured as well as from the configuration pvt
once the configuration has been loaded.
(closes issue https://issues.asterisk.org/view.php?id=17450)
Reported by: nahuelgreco
Patches:
patch.diff uploaded by jrose (license 1225)
Tested by: tilghman, jrose
Review: https://reviewboard.asterisk.org/r/1170/
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=313432
Issue History
Date Modified Username Field Change
======================================================================
2011-04-12 13:12 svnbot Checkin
2011-04-12 13:12 svnbot Note Added: 0133665
======================================================================
More information about the asterisk-bugs
mailing list