Andrei Pelinescu-Onciul wrote:
On May 20, 2010 at 13:53, marius zbihlei <[email protected]> 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
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
