[asterisk-bugs] [JIRA] Feedback Entered: (ASTERISK-20437) Deadlock with ast_context_remove_extension_callerid and handle_request_do
Jeff Hutchins (JIRA)
noreply at issues.asterisk.org
Tue Sep 18 12:40:27 CDT 2012
[ https://issues.asterisk.org/jira/browse/ASTERISK-20437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Hutchins updated ASTERISK-20437:
-------------------------------------
Status: Open (was: Waiting for Feedback)
> 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
More information about the asterisk-bugs
mailing list