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@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