[asterisk-dev] need help debugging a deadlock in 1.6.2.13

[Steve Davies]

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 1.6.2.13, 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
load.

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

Regards,
Steve