[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/#review7299
-----------------------------------------------------------



/branches/1.8/main/channel.c
<https://reviewboard.asterisk.org/r/2152/#comment14094>

    I think this should be made a new API call in the generator set and recommended for future use, so something like this doesn't happen for other generator usage.



/branches/1.8/main/channel.c
<https://reviewboard.asterisk.org/r/2152/#comment14093>

    Why not just get out of here earlier and reduce the indentation?


- Joshua


On Oct. 5, 2012, 1:50 p.m., Brent Eagles wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2152/
> -----------------------------------------------------------
> 
> (Updated Oct. 5, 2012, 1:50 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/20121018/c6f73135/attachment.htm>