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

[Santiago Gimeno]

Hi,

Have you got any update on this issue?

Thank you and sorry for the inconvenience.

Best regards,

Santi

2010/5/26 Andrei Pelinescu-Onciul <andrei at iptel.org>

> On May 25, 2010 at 17:10, marius zbihlei <marius.zbihlei at 1and1.ro> wrote:
> > 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.
>
>
> I don't like it. It would induce a performance hit (depending on the
> arch. and the locking method used).  While the performance hit of a
> single locking operation will be small, given the number of
> locks/unlocks we do under heavy traffic it will have a measurable impact
> on the overall performance.
> Moreover it's only use would be to "hide" bugs in the code (IMHO locking
> twice it's a bug).
>
> >
> > If the recursive mutex solution is not desired, what can we do to
> > prevent these types of deadlocks  ?
>
> Well, there is no general solution and I'm not familiar with the dialog
> code in question. Somehow locking twice should be avoided (unsafe
> callback called from failure route?).
>
> Does the same deadlock appears with 3.0/sip-router?
> >
> > 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
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20100607/defea9e8/attachment.htm>