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

[Brent Eagles]

> On Oct. 18, 2012, 9:12 a.m., Joshua Colp wrote:
> > /branches/1.8/main/channel.c, line 8192
> > <https://reviewboard.asterisk.org/r/2152/diff/2/?file=31763#file31763line8192>
> >
> >     Why not just get out of here earlier and reduce the indentation?

I was trying to reduce the number of special case unlock() statements without resorting to goto. That being said, if it is more in the spirit of things then sure why not?


- Brent


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


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/20121101/e0c60b1b/attachment.htm>