[asterisk-dev] [Code Review] 3042: chan_pjsip: Fixup function is blocking when attempting to push a synchronous task which can lead to a stuck channel container lock.

Joshua Colp reviewboard at asterisk.org
Thu Dec 5 12:18:25 CST 2013


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

Ship it!


Code-wise this is what I'd expect and will do as advertised, but my comment about uncharted territory remains.

- Joshua Colp


On Dec. 5, 2013, 6:14 p.m., Jonathan Rose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3042/
> -----------------------------------------------------------
> 
> (Updated Dec. 5, 2013, 6:14 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Mark Michelson, and rmudgett.
> 
> 
> Bugs: ASTERISK-22936
>     https://issues.asterisk.org/jira/browse/ASTERISK-22936
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This is a pretty severe locking problem which if triggered will cause Asterisk to become unusable. Basically when attended transferring a bridge in a way that triggers a masquerade, the ast_sip_push_task_synchronous function is unable to complete and we are stuck holding the channels container lock forever. The only simple answer to this problem is to not push the task synchronously and allow the fixup function to run some time later.
> 
> According to Josh and Mark, this hasn't been done before and there is a bit of fear that allowing the task processor to operate on a zombie channel could cause problems.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_pjsip.c 403308 
> 
> Diff: https://reviewboard.asterisk.org/r/3042/diff/
> 
> 
> Testing
> -------
> 
> Performed the attended transfer described on the issue without ending up in a state with locks being held. Prior to the patch, this would occur 100% of the time.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131205/28767aa9/attachment.html>


More information about the asterisk-dev mailing list