Andrei Pelinescu-Onciul wrote:
On May 20, 2010 at 13:53, marius zbihlei marius.zbihlei@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