17 Oct
2014
17 Oct
'14
5:58 a.m.
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@entry=0x7fff090c1210, a=a@entry=0x7fcac18fdc70,
msg=msg@entry=0x7fcabf22b3c0)
at action.c:1105
#6 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c1210, a=0x7fcac18fdc70,
msg=0x7fcabf22b3c0) at action.c:1599
#7 0x0000000000428bf4 in run_actions_safe (h=h@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@entry=0x7fcac18fddb8,
cache=cache@entry=0x0) at rvalue.c:924
#9 0x00000000004e1ad4 in rval_expr_eval_int (h=0x7fff090c21f0, msg=0x7fcabf22b3c0,
res=res@entry=0x7fff090c15c0,
rve=0x7fcac18fddb0) at rvalue.c:1918
#10 0x00000000004e1bae in rval_expr_eval_int (h=h@entry=0x7fff090c21f0,
msg=msg@entry=0x7fcabf22b3c0, res=res@entry=0x7fff090c17c0,
rve=rve@entry=0x7fcac18fe4d0) at rvalue.c:1926
#11 0x0000000000420f56 in do_action (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac18fee10,
msg=msg@entry=0x7fcabf22b3c0)
at action.c:1075
#12 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c21f0, a=0x7fcac18fee10,
msg=msg@entry=0x7fcabf22b3c0) at action.c:1599
#13 0x0000000000421128 in do_action (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac1cb09f0,
msg=msg@entry=0x7fcabf22b3c0)
at action.c:715
#14 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac1c33d98,
msg=msg@entry=0x7fcabf22b3c0)
at action.c:1599
#15 0x0000000000428c80 in run_top_route (a=0x7fcac1c33d98, msg=msg@entry=0x7fcabf22b3c0,
c=c@entry=0x0) at action.c:1685
#16 0x00007fcabefe703a in run_failure_handlers (t=t@entry=0x7fcaaf0386f0,
rpl=0x7fcac1fc2f88, code=500,
extra_flags=extra_flags@entry=0) at t_reply.c:1061
#17 0x00007fcabefe8617 in t_should_relay_response (Trans=Trans@entry=0x7fcaaf0386f0,
new_code=new_code@entry=500,
branch=branch@entry=0, should_store=should_store@entry=0x7fff090c24d0,
should_relay=should_relay@entry=0x7fff090c24c0,
cancel_data=cancel_data@entry=0x7fff090c26c0, reply=reply@entry=0x7fcac1fc2f88) at
t_reply.c:1416
#18 0x00007fcabefeab79 in relay_reply (t=t@entry=0x7fcaaf0386f0,
p_msg=p_msg@entry=0x7fcac1fc2f88, branch=0,
msg_status=msg_status@entry=500, cancel_data=cancel_data@entry=0x7fff090c26c0,
do_put_on_wait=do_put_on_wait@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@entry=0x7fcac1fc2f88,
mode=mode@entry=0) at forward.c:777
#21 0x000000000046dec7 in forward_reply (msg=msg@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.