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

[Mark Michelson]

> On Oct. 18, 2012, 9:12 a.m., Joshua Colp wrote:
> > /branches/1.8/main/channel.c, line 8189
> > <https://reviewboard.asterisk.org/r/2152/diff/2/?file=31763#file31763line8189>
> >
> >     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.

I'm with Josh on this one. It seems like this could happen with other generators. There are two cases where generators might be deactivated:

1) I specifically think Generator X is running and I want to stop it from running any more. I should make sure I'm actually stopping Generator X.
2) I want whatever generator is on the channel to stop running. This could be because I want to start running my own generator on the channel. It could also happen during channel destruction.


- Mark


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


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/20121019/205ca336/attachment-0001.htm>