[asterisk-bugs] [JIRA] (ASTERISK-19639) [patch] - Deadlock in queue with attended transfer

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-19639:
----------------------------------------

Good news! With a bit of trolling through the history that Paul provided in #asterisk-dev, this particular piece of "crappy code" has already been fixed.

The locking inversion occurred because of the following:
 * Masquerade locks the channel. During the masquerade, the app_queue fixup function is called, grabbing the Queue lock.
 * At the same time, calling get_queue_member_status *can* cause the channel to be locked. If get_queue_member_status is called within the Queue lock, this causes a deadlock.

However, in r378663, rmudgett modified the code in this place such that it no longer calls get_queue_member_status in the first place (note that this was done as part of the cleanup in ASTERISK-16115; see [this patch here|https://issues.asterisk.org/jira/secure/attachment/45753/jira_asterisk_16115_single_q_v1.8.patch]). Now, since all we need to do there is clear their status, that is done via {{member_call_pending_clear}} - which, while it locks the queue member, does not have to go out to the device state/extension state core.

Since this no longer appears to be a bug in the latest Asterisk 1.8, I'm going to go ahead and close this out as Fixed.
                
> [patch] - Deadlock in queue with attended transfer
> --------------------------------------------------
>
>                 Key: ASTERISK-19639
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19639
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 1.8.9.3
>            Reporter: Byron Clark
>         Attachments: backtrace.txt, queue_memberstatus_deadlock.patch
>
>
> I haven't been able to find an easy way to reproduce this deadlock, but from the backtrace it appears to happen when a transfer occurs on a queue agent while a new caller is entering the queue. That said, it seems to be somewhat rare.

--
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