[sr-dev] [Fwd: Re: [SR-Users] Kamailio 1.5 stops processing messages]

[marius zbihlei]

Andrei Pelinescu-Onciul wrote:
> On May 20, 2010 at 13:53, marius zbihlei <marius.zbihlei at 1and1.ro> wrote:
>   
>> Forwarded the message from sr-users to sr-dev list
>>
>> Cheers
>> Marius
>>     
>
> [...]
>   
>> Hello
>>
>> I am a little busy atm, so before I dig into the code, I have a
>> question for core devs. Is the LOCK_HASH() call  recursive (being
>> called again from the same process will not block) ? I ask this
>> because in the 4th blocked INVITE the hash _might_ be blocked by
>> both t_newtran(#16 0xb7b535fa in t_newtran (p_msg=0x81f18a8) at
>> t_lookup.c:1064)
>>     
>
> No it's not recursive (it will deadlock if called twice for the same
> entry in the same process). This is true for all *ser versions
> (sip-router, kamailio < 3.0, ser *).
>
>   
Hello Andrei

I have looked thru the code and it seems this is the case. While the 
transaction is locked in t_newtrans(), the tm callbacks are called, 
which call the pua_dialog callback, which in turn call a transaction 
function that requires the same lock; so the mutex is locked twice from 
the same process. Is there anyway we can prevent this from the future? 
One way is to patch pua_dialog so it doesn't call t_uac()(?) but this 
still leaves the possibility of another lock happening somewhere else. I 
was thinking that a better approach was implementing a recursive mutex.

If the recursive mutex solution is not desired, what can we do to 
prevent these types of deadlocks  ?

Marius
>> and 6  t_uac (#6  0xb7b6ce01 in t_uac (method=0xbff60558,
>> headers=0x81e3108, body=0x81d9afb, dialog=0xa772c6a8, cb=0xb734a622
>> <publ_cback_func>, cbp=0xa7715158)), thus causing a deadlock.
>>
>>     
>
>
> Andrei
>
>