[asterisk-dev] [Code Review]: Call pickup race leaves orphaned channels or crashes.

Alec Davis reviewboard at asterisk.org
Tue Aug 30 15:53:08 CDT 2011



> On Aug. 30, 2011, 2:55 p.m., Alec Davis wrote:
> > I believe we are dealling with 2 issues.
1). This fix, which catches the creation of dead channels, which is good.
2). Pickup which can invoke dead channels, which is what we're using to invoke them. Other situations may too.

I'm still in favour of the pickup datastore (or some similar method) on the caller channel to tidy up pickups of multiple legs of a single call, as was done for race detection of 2 channels picking up the exact same channel. Then we don't get to the masquerade which is too late.

The senario I've been using is;
Parent lets their kids go to school but tells them only one is allowed out after school.
Both kids are invited out by friends, both kids say yes.
Kids get home not knowing that the other has been invited out.
Parent who is the masquerader can only deliver 1 kid. It's too late.
Had the kids been able to ring parent with cell phone to check, all would have been ok, well at least the 2nd kid would have been told no.

I shouldn't have used favour in my last comment. This fix is correct.

I should have used: in addition to this fix, we should somehow mark the parent caller channel 'as being picked up' so that the other legs are aware, but only for the duration of the pickup.


- Alec


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


On Aug. 30, 2011, 2:28 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1400/
> -----------------------------------------------------------
> 
> (Updated Aug. 30, 2011, 2:28 p.m.)
> 
> 
> Review request for Asterisk Developers, Alec Davis and irroot.
> 
> 
> Summary
> -------
> 
> Attempting to pickup a call that has been forked to multiple extensions by two users either crashes or fails a masquerade with a "bad things may happen" message.
> 
> This is the scenario that is causing all the grief:
> 1) Pickup target is selected
> 2) target is marked as being picked up in ast_do_pickup()
> 3) target is unlocked by ast_do_pickup()
> 4) app dial or queue gets a chance to hang up losing calls and calls ast_hangup() on target
> 5) SINCE A MASQUERADE HAS NOT BEEN SETUP YET BY ast_do_pickup() with ast_channel_masquerade(), ast_hangup() completes successfully and the channel is no longer in the channels container.
> 6) ast_do_pickup() then calls ast_channel_masquerade() to schedule the masquerade on the dead channel.
> 7) ast_do_pickup() then calls ast_do_masquerade() on the dead channel
> 8) bad things happen while doing the masquerade and in the process ast_do_masquerade() puts the dead channel back into the channels container
> 9) The "orphaned" channel is visible in the channels list if a crash does not happen.
> 
> This patch does the following:
> 1) ast_hangup() sets the zombie flag on a successfully hung-up channel and does not release the channel lock until that has happened.
> 2) __ast_channel_masquerade() is fixed to not setup a masquerade if either channel is a zombie.
> 
> 
> This addresses bugs ASTERISK-18222 and ASTERISK-18273.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18222
>     https://issues.asterisk.org/jira/browse/ASTERISK-18273
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_agent.c 333945 
>   /branches/1.8/main/channel.c 333945 
> 
> Diff: https://reviewboard.asterisk.org/r/1400/diff
> 
> 
> Testing
> -------
> 
> Replicated the crash in ASTERISK-18222 with PickupChan() and *8 methods.
> 
> With the patch, the crash no longer happens and the new message of attempting to masquerade into a dead channel is output.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

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


More information about the asterisk-dev mailing list