9 Apr
2014
9 Apr
'14
10:34 p.m.
Hello,
that should not be a very rare case and I would expect to be caught so
far, anyhow ... this looks like easy to reproduce, have you tried it?
You can have two kamailio, one relying the invite to the second, which
will reply with 100, then wait for the timeout on the first instance.
You can add some debug messages in the code to see if the lock is called
twice.
Cheers,
Daniel
On 09/04/14 17:51, Jason Penton wrote:
Hi All,
I have been experiencing a deadlock when a timeout occurs on a
t_relayed() INVITE. Going through the code I have noticed a possible
chance of deadlock (without re-entrant enabled). Here is my thinking:
t_should_relay_response() is called with REPLY_LOCK when the timer
process fires on the fr_inv_timer (no response from the INVITE that
was relayed, other than 100 provisional) and a 408 is generated.
However, from within that function there are calls
to run_failure_handlers() which in turn *could* try and lock the reply
(viz. somebody having a t_reply() call in the cfg file - in failure
route block). This would result in another lock on the same
transaction's REPLY_LOCK....
Has anybody else experienced something like this?
this is on master btw.
Cheers
Jason
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda