[asterisk-bugs] [JIRA] Status Changed to Waiting for Development: (ASTERISK-20437) Deadlock with ast_context_remove_extension_callerid and handle_request_do

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-20437:
------------------------------------

    Status: Open  (was: Triage)

> Deadlock with ast_context_remove_extension_callerid and handle_request_do
> -------------------------------------------------------------------------
>
>                 Key: ASTERISK-20437
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20437
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Subscriptions
>    Affects Versions: 1.8.9.3
>            Reporter: Jeff Hutchins
>         Attachments: backtrace.full.txt, backtrace.txt
>
>
> As can be seen in the attached backtrace files thread 25 obtains a sip_pvt lock (0x2aaabc46b658) at chan_sip.c:25270 (#9 in thread 25) with a call to sip_pvt_lock_full and then later in the stack trace (#5 in thread 25) tries to acquire a context lock at pbx.c:4302 with a call to ast_rdlock_context. At the same time thread 2 obtains a context lock at pbx.c:5580 (#12 in thread 2) with a call to find_context_locked(context) which in turn calls ast_rdlock_context and then later in it's stack trace thread 2 attempts to obtain a sip_pvt lock (0x2aaabc46b658) at chan_sip.c:14485 (#5 in thread 2) with a call to sip_pvt_lock_full. This naturally causes a deadlock as each thread holds the resource the other is trying to acquire. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira