----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3908/#review13103 -----------------------------------------------------------
/branches/12/res/res_stasis.c <https://reviewboard.asterisk.org/r/3908/#comment23553> This will not tell you if the channel is actually still in a bridge. The /continue request will have bridge non-NULL. Also the command_queue has no way of discarding any pending commands without leaking memory or ao2 objects since the command data could be either malloced memory or an ao2 object. - rmudgett On Aug. 14, 2014, 1:46 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3908/ > ----------------------------------------------------------- > > (Updated Aug. 14, 2014, 1:46 p.m.) > > > Review request for Asterisk Developers, kmoore, Matt Jordan, and rmudgett. > > > Bugs: ASTERISK-24147 > https://issues.asterisk.org/jira/browse/ASTERISK-24147 > > > Repository: Asterisk > > > Description > ------- > > Here's a basic rundown of what was happening: > > 1. Stasis application with a channel in it, channel is in a bridge. Playback > actions for the channel are queued, the stasis control is running them. > > 2. The channel hangs up. Because the stasis control detects a hangup and the > depart is expected to be handled when the channel leaves the bridge, the > stasis application execution function exits taking the control along with it. > When the PBX thread exits, the channel is considered fully hung up and leaves > the bridging core. At this point we are running after bridge callbacks with, > one of which holds a pointer to a dead control object that we are trying to > do all queue actions to along with other things. This causes the crash. > > In order to fix this, I made sure that if the control execution loop is > exited without pulling the channel out of the bridge that the channel depart > would occur manually and the control would be marked so that the after bridge > cb wouldn't attempt to exit the bridge in this case. This wasn't actually > causing problems, but Richard and I both have concerns about an after bridge > callback attempting to depart a channel from a bridge... it seems a little > out there. > > > Diffs > ----- > > /branches/12/res/stasis/control.c 420938 > /branches/12/res/res_stasis.c 420938 > > Diff: https://reviewboard.asterisk.org/r/3908/diff/ > > > Testing > ------- > > Made sure the crash that was happening no longer occurs > > Tested long queues of playback to check what would happen with the additional > playbacks. Each subsequent playback from the one currently running fails (in > an expected manner) and reports its failure over stasis. Nothing too odd > there. > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
