[asterisk-bugs] [JIRA] (ASTERISK-20537) Asterisk deadlocks between looking up extension from process_sdp and bridge execution from pbx_realtime

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-20537:
----------------------------------------

Thank you for reporting this issue.  {{pbx_realtime}} is an extended support module, and as such, developer support for it comes primarily from the Asterisk developer community.  Response times may reflect that.
                
> Asterisk deadlocks between looking up extension from process_sdp and bridge execution from pbx_realtime
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20537
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20537
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, PBX/pbx_realtime
>    Affects Versions: 1.8.16.0
>         Environment: Linux CentOs
>            Reporter: Yaroslav Radilov
>         Attachments: backtrace-threads.txt, core-show-locks.txt
>
>
> I have got lock on asterisk 1.8.16.0. Lock happens once week on incoming call. It happens in different points of dialplan. Files with backtrace and core show locks included.
> [mjordan edit]:
> Deadlock appears to be between {{ast_write}} called from bridge initiated from {{pbx_realtime}} and attempting to stop the autoservice on the channel (called from {{ast_exists_extension}} from {{process_sdp}}).  The problem here is that the autoservice waits indefinitely until the channel comes out of autoservice, which it can't do since the channel is already locked by {{chan_sip}}.
> The channel cannot be locked when calling {{ast_exists_extension}}.
> Quoting from the source header:
> {code}
>  * \note It is possible for autoservice to be started and stopped on c during this
>  * function call, it is important that c is not locked prior to calling this. Otherwise
>  * a deadlock may occur
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira