[asterisk-dev] need help debugging a deadlock in

Steve Davies davies147 at gmail.com
Wed Oct 6 15:50:13 CDT 2010

On 6 October 2010 21:33, Antonio Goméz Soto
<antonio.gomez.soto at gmail.com> wrote:
> Op 05-10-10 22:31, Russell Bryant schreef:
>> ----- Original Message -----
>>> Hello,
>>> I am new to this list. I have a deadlock in, that I am trying
>>> to debug myself.
>>> What happens is there are two threads that lock resources in a
>>> different order causing a deadlock.
>>> The threads are:
>>> 1. from taskprocessor handle_statechange() is called.
>>> This one locks ast_rdlock_contexts, and then eventually call
>>> cb_extensionstate()
>>> which immediately does a sip_pvt_lock()
>>> 2. do_monitor calls sipsock_read() which calls handle_request_do()
>>> which calls
>>> find_call(), which does a sip_pvt_lock() too.
>>> The incoming request is a subscription, so it calls ast_get_hint(),
>>> which calls
>>> ast_hint_extension() which calls ast_rdlock_contexts(). Deadlock.
>>>  From what I know, I'd say the last thread uses the wrong order. It
>>> would probably
>>> not be appropriate to lock the contexts for each incoming request
>>> would it?
>>> Can anyone suggest how to handle this?
>> I have a patch that I started working on last week for Asterisk 1.4 that would address this deadlock.  It will eventually have to be ported to all versions of Asterisk.
>> The change that I made was to change the operation of thread #1.  I modified the storage of hints to use astobj2.  The code path in #1 no longer holds the hints lock and contexts lock while processing each configured hint.
> Russell,
> is there an open issue for this?
> Thanks,
> Antonio

I will add a "me too" to this. We can cause this type of deadlock
quite easily by generating lots of BLF hinting traffic under high call

I'd be happy to port and/or test this patch on


More information about the asterisk-dev mailing list