[asterisk-dev] need help debugging a deadlock in 188.8.131.52
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 -----
>>> I am new to this list. I have a deadlock in 184.108.40.206, 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
>>> 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.
> is there an open issue for this?
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 220.127.116.11.
More information about the asterisk-dev