[asterisk-dev] [Code Review] Patch to prevent stopping the active generator when it is not the silence generator.

[Joshua Colp]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2152/#review7375
-----------------------------------------------------------

Ship it!


- Joshua


On Nov. 1, 2012, 12:14 p.m., Brent Eagles wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2152/
> -----------------------------------------------------------
> 
> (Updated Nov. 1, 2012, 12:14 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Stopping the silence generator does not take into account that it may no longer be the active generator. This patch adds a small internal function that is currently only used for silence generator related code. It might be useful to add to the public API later on, or at the very least, everywhere in channel.c where stopping an generator is only valid if the current generator is as expected. This patch also adds a lock/unlock block around an unprotected assignment to chan->generatordata that also checks to see if the current generator is the one that is expected (there are almost certainly other spots that need looked at, but this little bit is itself creep).
> 
> 
> This addresses bug ASTERISK-19918.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19918
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/channel.c 374534 
> 
> Diff: https://reviewboard.asterisk.org/r/2152/diff
> 
> 
> Testing
> -------
> 
> The problem as reported by the user was eventually reproduced by establishing configuration details inferred from the reporter's provided debug logs. Namely, enabling a configuration item that enables silence generation. A simple queue configuration with agent login reproduced the issue pretty reliably. The same actions were performed with the patch in place and music on hold resumed as expected.
> 
> 
> Thanks,
> 
> Brent
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121108/d3d7b7d6/attachment.htm>