[sr-dev] [tracker] Task changed: deadlock if calling t_check_trans() from failure route

[sip-router]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has been changed.  The changes are listed below.  For full information about what has changed, visit the URL and click the History tab.

FS#482 - deadlock if calling t_check_trans() from failure route
User who did this: Daniel-Constantin Mierla (miconda)
Task details edited:
-------
Hello, i have a route that i use for rejecting the call with an option to play announcement. This is called from the request or from failure_route:

<code>
route[ROUTE_EARLY_REJECT]
{
        if(!t_check_trans())
        {
                t_newtran();
        }
        if($var(announce_set) == 0)
        {
                route(ROUTE_ADD_CALLINFO_REPLY);
                t_reply("$avp(s:announce_code)", "$avp(s:announce_reason)");
                exit;
        } else {
        # play announcement
...
}

</code>

Now If I call it from the failure_route I get some kind of deadlock, where kamailio (4.1.6) is eating 100% cpu. If I kill it with SIGABRT I get this backtrace:

<code>
Program terminated with signal 6, Aborted.
#0  0x00007fcac3283fb7 in sched_yield () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007fcac3283fb7 in sched_yield () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fcabefe9275 in get_lock (lock=0x7fcaaf039c88) at ../../parser/../mem/../fastlock.h:307
#2  _lock (s=0x7fcaaf039c88) at lock.h:99
#3  t_retransmit_reply (t=0x7fcaaf0386f0) at t_reply.c:1600
#4  0x00007fcabf00798b in t_check_trans (msg=0x7fcabf22b3c0) at tm.c:2139
#5  0x0000000000420ba0 in do_action (h=h at entry=0x7fff090c1210, a=a at entry=0x7fcac18fdc70, msg=msg at entry=0x7fcabf22b3c0)
    at action.c:1105
#6  0x000000000041fb70 in run_actions (h=h at entry=0x7fff090c1210, a=0x7fcac18fdc70, msg=0x7fcabf22b3c0) at action.c:1599
#7  0x0000000000428bf4 in run_actions_safe (h=h at entry=0x7fff090c21f0, a=<optimized out>, msg=<optimized out>) at action.c:1664
#8  0x00000000004dc730 in rval_get_int (h=0x7fff090c21f0, msg=<optimized out>, i=0x7fff090c15c0, rv=rv at entry=0x7fcac18fddb8, 
    cache=cache at entry=0x0) at rvalue.c:924
#9  0x00000000004e1ad4 in rval_expr_eval_int (h=0x7fff090c21f0, msg=0x7fcabf22b3c0, res=res at entry=0x7fff090c15c0, 
    rve=0x7fcac18fddb0) at rvalue.c:1918
#10 0x00000000004e1bae in rval_expr_eval_int (h=h at entry=0x7fff090c21f0, msg=msg at entry=0x7fcabf22b3c0, res=res at entry=0x7fff090c17c0, 
    rve=rve at entry=0x7fcac18fe4d0) at rvalue.c:1926
#11 0x0000000000420f56 in do_action (h=h at entry=0x7fff090c21f0, a=a at entry=0x7fcac18fee10, msg=msg at entry=0x7fcabf22b3c0)
    at action.c:1075
#12 0x000000000041fb70 in run_actions (h=h at entry=0x7fff090c21f0, a=0x7fcac18fee10, msg=msg at entry=0x7fcabf22b3c0) at action.c:1599
#13 0x0000000000421128 in do_action (h=h at entry=0x7fff090c21f0, a=a at entry=0x7fcac1cb09f0, msg=msg at entry=0x7fcabf22b3c0)
    at action.c:715
#14 0x000000000041fb70 in run_actions (h=h at entry=0x7fff090c21f0, a=a at entry=0x7fcac1c33d98, msg=msg at entry=0x7fcabf22b3c0)
    at action.c:1599
#15 0x0000000000428c80 in run_top_route (a=0x7fcac1c33d98, msg=msg at entry=0x7fcabf22b3c0, c=c at entry=0x0) at action.c:1685
#16 0x00007fcabefe703a in run_failure_handlers (t=t at entry=0x7fcaaf0386f0, rpl=0x7fcac1fc2f88, code=500, 
    extra_flags=extra_flags at entry=0) at t_reply.c:1061
#17 0x00007fcabefe8617 in t_should_relay_response (Trans=Trans at entry=0x7fcaaf0386f0, new_code=new_code at entry=500, 
    branch=branch at entry=0, should_store=should_store at entry=0x7fff090c24d0, should_relay=should_relay at entry=0x7fff090c24c0, 
    cancel_data=cancel_data at entry=0x7fff090c26c0, reply=reply at entry=0x7fcac1fc2f88) at t_reply.c:1416
#18 0x00007fcabefeab79 in relay_reply (t=t at entry=0x7fcaaf0386f0, p_msg=p_msg at entry=0x7fcac1fc2f88, branch=0, 
    msg_status=msg_status at entry=500, cancel_data=cancel_data at entry=0x7fff090c26c0, do_put_on_wait=do_put_on_wait at entry=1)
    at t_reply.c:1819
#19 0x00007fcabefee3f4 in reply_received (p_msg=0x7fcac1fc2f88) at t_reply.c:2499
#20 0x000000000046d486 in do_forward_reply (msg=msg at entry=0x7fcac1fc2f88, mode=mode at entry=0) at forward.c:777
#21 0x000000000046dec7 in forward_reply (msg=msg at entry=0x7fcac1fc2f88) at forward.c:860
#22 0x00000000004b7f7e in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>) at receive.c:273
---Type <return> to continue, or q <return> to quit---
#23 0x00000000005538e1 in udp_rcv_loop () at udp_server.c:536
#24 0x000000000047b672 in main_loop () at main.c:1619
#25 0x000000000041f585 in main (argc=<optimized out>, argv=<optimized out>) at main.c:2547
</code>

I need t_newtran() in case I'm calling this from request route, because I'm using t_reply() so I can workaround this by doing:

<code>
        if(!t_check_trans() && !t_is_failure_route())
        {
                t_newtran();
        }
</code>

Is this expected to have a deadlock if calling t_check_trans() from failure route?
-------

More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=482

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.