[asterisk-bugs] [JIRA] Feedback Entered: (ASTERISK-20437) Deadlock with ast_context_remove_extension_callerid and handle_request_do

[Jeff Hutchins (JIRA)]

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

Jeff Hutchins updated ASTERISK-20437:
-------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

For an uncommon deadlock like this running with DEBUG_THREADS and DONT_OPTIMIZE on our production machines is not really an option as it is significantly less performant. However, the core-show-locks should not actually be required since I already did the leg work of finding the deadlock and explaining the exact lines where the deadlocks are occurring.

The newest version of certified asterisk is 1.8.11 and there has only been 3 deadlock fixes between 1.8.9.3 and 1.8.11 none of which are pertinent to this issue. Which version of asterisk would you suggest I try?



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