[asterisk-bugs] [JIRA] (ASTERISK-22936) Deadlock during masquerade when a PJSIP channel attended transfers a 3+ party bridge to dialplan

[Mark Michelson (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=212460#comment-212460 ] 

Mark Michelson commented on ASTERISK-22936:
-------------------------------------------

Yuck. It looks like there are two masquerades happening at the same time and they are deadlocking. This...this is just the most disgusting thing I've ever seen.

It's weird that the one in the bottom thread of lockdata.txt is not completing though. I wonder what it is that's causing it to block indefinitely. Attaching gdb during the deadlock could probably be useful so you can inspect the stacks and find out the circumstances (like what channels are involved) behind the masquerades.
                
> Deadlock during masquerade when a PJSIP channel attended transfers a 3+ party bridge to dialplan
> ------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22936
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22936
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Resources/res_pjsip_refer
>    Affects Versions: SVN, 12.0.0-beta2, 12.0.0
>         Environment: Ubuntu 13.10 64-bit
>            Reporter: Jonathan Rose
>            Severity: Critical
>         Attachments: lockdata.txt
>
>
> If a PJSIP channel attended transfers a three-way call to dialplan (as opposed to another bridge), Asterisk will attempt to masquerade swap a local channel with the transferer's channel that is currently in the dial plan. I've tracked this to a sticking point in ast_do_masquerade. An attempt to lock the channels container never returns.
> I tried a similar transfer scenario with chan_sip and that worked fine, so it seems likely that we are breaking some (possibly unwritten) rules when issuing ast_bridge_transfer_attended from res_pjsip_refer.c
> I've marked this issue as critical since this bug can easily be triggered by any PJSIP line with the ability to do attended transfers and once it has happened Asterisk becomes less than usable since the channels container lock is stuck. Yay masquerades.
> Steps for reproduction:
> * Start a three way call.  At least one of the three channels must be a PJSIP line.
> * Perform a SIP attended transfer from the PJSIP line to an extension that will linger in the dialplan.  Answer to Wait(20) works just fine.
> * Complete the transfer. The transfer will fail and the channels lock will be stuck preventing any new channels from being made and preventing
>   old channels from... doing lots of stuff.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira