Hi,<br><br>Have you got any update on this issue?<br><br>Thank you and sorry for the inconvenience.<br><br>Best regards,<br><br>Santi<br><br><div class="gmail_quote">2010/5/26 Andrei Pelinescu-Onciul <span dir="ltr"><<a href="mailto:andrei@iptel.org">andrei@iptel.org</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div class="h5">On May 25, 2010 at 17:10, marius zbihlei <<a href="mailto:marius.zbihlei@1and1.ro">marius.zbihlei@1and1.ro</a>> wrote:<br>
> Andrei Pelinescu-Onciul wrote:<br>
> >On May 20, 2010 at 13:53, marius zbihlei <<a href="mailto:marius.zbihlei@1and1.ro">marius.zbihlei@1and1.ro</a>> wrote:<br>
> >>Forwarded the message from sr-users to sr-dev list<br>
> >><br>
> >>Cheers<br>
> >>Marius<br>
> ><br>
> >[...]<br>
> >>Hello<br>
> >><br>
> >>I am a little busy atm, so before I dig into the code, I have a<br>
> >>question for core devs. Is the LOCK_HASH() call recursive (being<br>
> >>called again from the same process will not block) ? I ask this<br>
> >>because in the 4th blocked INVITE the hash _might_ be blocked by<br>
> >>both t_newtran(#16 0xb7b535fa in t_newtran (p_msg=0x81f18a8) at<br>
> >>t_lookup.c:1064)<br>
> ><br>
> >No it's not recursive (it will deadlock if called twice for the same<br>
> >entry in the same process). This is true for all *ser versions<br>
> >(sip-router, kamailio < 3.0, ser *).<br>
> ><br>
> Hello Andrei<br>
><br>
> I have looked thru the code and it seems this is the case. While the<br>
> transaction is locked in t_newtrans(), the tm callbacks are called,<br>
> which call the pua_dialog callback, which in turn call a transaction<br>
> function that requires the same lock; so the mutex is locked twice<br>
> from the same process. Is there anyway we can prevent this from the<br>
> future? One way is to patch pua_dialog so it doesn't call t_uac()(?)<br>
> but this still leaves the possibility of another lock happening<br>
> somewhere else. I was thinking that a better approach was<br>
> implementing a recursive mutex.<br>
<br>
<br>
</div></div>I don't like it. It would induce a performance hit (depending on the<br>
arch. and the locking method used). While the performance hit of a<br>
single locking operation will be small, given the number of<br>
locks/unlocks we do under heavy traffic it will have a measurable impact<br>
on the overall performance.<br>
Moreover it's only use would be to "hide" bugs in the code (IMHO locking<br>
twice it's a bug).<br>
<div class="im"><br>
><br>
> If the recursive mutex solution is not desired, what can we do to<br>
> prevent these types of deadlocks ?<br>
<br>
</div>Well, there is no general solution and I'm not familiar with the dialog<br>
code in question. Somehow locking twice should be avoided (unsafe<br>
callback called from failure route?).<br>
<br>
Does the same deadlock appears with 3.0/sip-router?<br>
<div><div></div><div class="h5">><br>
> Marius<br>
> >>and 6 t_uac (#6 0xb7b6ce01 in t_uac (method=0xbff60558,<br>
> >>headers=0x81e3108, body=0x81d9afb, dialog=0xa772c6a8, cb=0xb734a622<br>
> >><publ_cback_func>, cbp=0xa7715158)), thus causing a deadlock.<br>
> >><br>
> ><br>
<br>
Andrei<br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br>