sr master crashes while parsing uri. looks like it is related to db acc_extra, but don't know which uri it was. actually, when i look at my db_extra var, it contains $ru and the rest are avps. so perhaps the crash came while parsing request-uri.
-- juha
Program terminated with signal 11, Segmentation fault. [New process 17398] #0 parse_uri (buf=0x20000000a <Address 0x20000000a out of bounds>, len=1249306511, uri=0x2b0fc2c9bb28) at parser/parse_uri.c:389 389 scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24); (gdb) where #0 parse_uri (buf=0x20000000a <Address 0x20000000a out of bounds>, len=1249306511, uri=0x2b0fc2c9bb28) at parser/parse_uri.c:389 #1 0x00000000004fe88f in parse_sip_msg_uri (msg=0x2b0fc2c9b748) at parser/parse_uri.c:1407 #2 0x00002b0fc11158d5 in pv_get_ruri (msg=0x2b0fc2c9bb28, param=0x984238, res=0x2b0fc2c9b9c8) at pv_core.c:207 #3 0x0000000000466743 in pv_get_spec_value (msg=0x2b0fc2c9b748, sp=0x984220, value=0x2b0fc2c9b9c8) at pvapi.c:988 #4 0x00002b0fc175167c in extra2strar (extra=0x984210, rq=0x2b0fc2c9b748, val_arr=<value optimized out>, int_arr=0x2b0fc1968f7c, type_arr=0x2b0fc19690c7 "") at acc_extra.c:262 #5 0x00002b0fc1750720 in acc_db_request (rq=0x2b0fc2c9b748) at acc.c:385 #6 0x00002b0fc1752bd8 in on_missed (t=<value optimized out>, req=0x2b0fc2c9b748, reply=<value optimized out>, code=503) at acc_logic.c:356 #7 0x00002b0fc1753654 in tmcb_func (t=0x2b0fc2c93ad0, type=<value optimized out>, ps=<value optimized out>) at acc_logic.c:399 #8 0x00002b0fbe84d1ac in run_trans_callbacks_internal ( cb_lst=0x2b0fc2c93b40, type=128, trans=0x2b0fc2c93ad0, params=0x7fffee58ed20) at t_hooks.c:290 #9 0x00002b0fbe84d40a in run_trans_callbacks (type=27, trans=<value optimized out>, req=0x246, rpl=0x20000000a, code=6) at t_hooks.c:317 #10 0x00002b0fbe86d8cc in _reply_light (trans=0x2b0fc2c93ad0, buf=0x8a4dc0 "SIP/2.0 503 Service not available\r\nVia: SIP/2.0/TCP 192.98.100.10;branch=z9hG4bK2ee1.89c63a36.0\r\nVia: SIP/2.0/UDP 192.168.0.169:5074;received=192.98.100.128;rport=62461;branch=z9hG4bKuukwknpo\r\nTo: <si"..., len=455, code=503, to_tag=<value optimized out>, to_tag_len=<value optimized out>, lock=1, bm=0x7fffee58eea0) ---Type <return> to continue, or q <return> to quit--- at t_reply.c:646 #11 0x00002b0fbe86eaf1 in _reply (trans=0x2b0fc2c93ad0, p_msg=0x8d77e0, code=503, text=<value optimized out>, lock=1) at t_reply.c:726 #12 0x00002b0fbe85df55 in w_t_reply_wrp (m=0x8d77e0, code=<value optimized out>, txt=<value optimized out>) at tm.c:1256 #13 0x00002b0fbf9362cd in send_reply (msg=0x8d77e0, code=503, reason=0x7fffee58f000) at sl.c:268 #14 0x00002b0fbf9365e5 in w_send_reply (msg=0x8d77e0, p1=<value optimized out>, p2=0x930d18 "xO\223") at sl.c:306 #15 0x0000000000415ab6 in do_action (h=0x7fffee5915c0, a=0x934d50, msg=0x8d77e0) at action.c:1100 #16 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x934d50, msg=0x8d77e0) at action.c:1588 #17 0x000000000041620c in do_action (h=0x7fffee5915c0, a=0x934fa0, msg=0x8d77e0) at action.c:1089 #18 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x934fa0, msg=0x8d77e0) at action.c:1588 #19 0x000000000041620c in do_action (h=0x7fffee5915c0, a=0x935090, msg=0x8d77e0) at action.c:1089 #20 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x933c60, msg=0x8d77e0) at action.c:1588 #21 0x000000000041620c in do_action (h=0x7fffee5915c0, a=0x935a10, msg=0x8d77e0) at action.c:1089 #22 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x935a10, msg=0x8d77e0) at action.c:1588 #23 0x0000000000415b57 in do_action (h=0x7fffee5915c0, a=0x942688, msg=0x8d77e0) at action.c:1392 #24 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x931f88, msg=0x8d77e0) at action.c:1588 ---Type <return> to continue, or q <return> to quit--- #25 0x00000000004176ff in do_action (h=0x7fffee5915c0, a=0x931c88, msg=0x8d77e0) at action.c:712 #26 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x92bfb8, msg=0x8d77e0) at action.c:1588 #27 0x00000000004176ff in do_action (h=0x7fffee5915c0, a=0x8d4858, msg=0x8d77e0) at action.c:712 #28 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x87dc00, msg=0x8d77e0) at action.c:1588 #29 0x00000000004176ff in do_action (h=0x7fffee5915c0, a=0x87cb58, msg=0x8d77e0) at action.c:712 #30 0x000000000041c462 in run_actions (h=0x7fffee5915c0, a=0x877578, msg=0x8d77e0) at action.c:1588 #31 0x000000000041c723 in run_top_route (a=0x877578, msg=0x8d77e0, c=<value optimized out>) at action.c:1661 #32 0x00000000004704fe in receive_msg ( buf=0x2b0fc2c8f430 "INVITE *********\r\n"..., len=<value optimized out>, rcv_info=0x2b0fc2c8f168) at receive.c:205 #33 0x00000000004cc1d1 in tcp_read_req (con=0x2b0fc2c8f150, bytes_read=0x7fffee591930, read_flags=0x7fffee59192c) at tcp_read.c:978 #34 0x00000000004ccc2e in handle_io (fm=0x98c1d8, events=1, idx=-1) at tcp_read.c:1150 #35 0x00000000004cf760 in tcp_receive_loop (unix_sock=<value optimized out>) at io_wait.h:1091 #36 0x00000000004a8fb7 in tcp_init_children () at tcp_main.c:4819 #37 0x000000000044da94 in main_loop () at main.c:1632 #38 0x000000000044ffd0 in main (argc=<value optimized out>, argv=0x7fffee591cd8) at main.c:2398
Juha Heinanen writes:
sr master crashes while parsing uri. looks like it is related to db acc_extra, but don't know which uri it was. actually, when i look at my db_extra var, it contains $ru and the rest are avps. so perhaps the crash came while parsing request-uri.
i analyzed this a bit more and crash happens when script calls drop in branch route due to the method not being supported by that particular branch.
that causes t_relay() to fail and script then calls next_gw() again and tries to find some other gw that would support the method. there is none and the script replies 503 and calls exit.
the crash happens when that failed call is being accounted. acc and acc missed flags are set before t_relay is called for the first time.
-- juha
On 12/17/10 8:10 AM, Juha Heinanen wrote:
Juha Heinanen writes:
the crash happens when that failed call is being accounted. acc and acc missed flags are set before t_relay is called for the first time.
i verified once more and there is a sure crash due to accounting when i call drop in branch route.
I tried to reproduce, but didn't get it: - call 123 - set accounting flags, including for missed calls - set t_on_branch(test) - in branch_route[test] i have drop
Can you describe a bit more your case? Is it one branch or more for these calls? Are all dropped or some are forwarded. It seems that there is a 503 reply processed while in the case of the single branch dropped should be generated a 500.
Cheers, Daniel
Daniel-Constantin Mierla writes:
I tried to reproduce, but didn't get it:
- call 123
- set accounting flags, including for missed calls
- set t_on_branch(test)
- in branch_route[test] i have drop
daniel,
did you have $ru in db_extra? i have:
modparam("acc", "db_extra", "translated_ruri=$ru;...")
Can you describe a bit more your case? Is it one branch or more for these calls? Are all dropped or some are forwarded. It seems that there is a 503 reply processed while in the case of the single branch dropped should be generated a 500.
i call t_relay only once before the crash happens and there is only one branch. script goes something like this:
setflag(ACC_FLAG); setflag(ACC_MISSED_FLAG); t_on_reply("REPLY"); t_on_failure("FAILURE");
while ($true) { if (!next_gw()) { send_reply("503", "Service not available"); exit; }; t_on_branch("BRANCHES"); if (t_relay()) exit; };
and in branch route i call drop.
-- juha
On 12/18/10 9:34 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I tried to reproduce, but didn't get it:
- call 123
- set accounting flags, including for missed calls
- set t_on_branch(test)
- in branch_route[test] i have drop
daniel,
did you have $ru in db_extra? i have:
modparam("acc", "db_extra", "translated_ruri=$ru;...")
Can you describe a bit more your case? Is it one branch or more for these calls? Are all dropped or some are forwarded. It seems that there is a 503 reply processed while in the case of the single branch dropped should be generated a 500.
i call t_relay only once before the crash happens and there is only one branch. script goes something like this:
setflag(ACC_FLAG); setflag(ACC_MISSED_FLAG); t_on_reply("REPLY"); t_on_failure("FAILURE"); while ($true) { if (!next_gw()) { send_reply("503", "Service not available"); exit; }; t_on_branch("BRANCHES"); if (t_relay()) exit; };and in branch route i call drop.
Yours a bit different -- you send 503 from main route upon t_relay() failure -- I will try it as well. I had:
branch_route[TEST] { drop; }
# Main SIP request routing logic # - processing of any incoming SIP request starts with this route route { setflag(FLT_ACC); setflag(FLT_ACCMISSED); t_on_branch("TEST"); t_relay(); exit; }
And the log was (102 calling 123):
11(30316) DEBUG: tm [t_reply.c:659]: DEBUG: reply sent out. buf=0x83040c0: SIP/2.0 100 trying -..., shmem=0xb596c89c: SIP/2.0 100 trying - 11(30316) DEBUG: tm [t_reply.c:669]: DEBUG: _reply_light: finished 11(30316) ERROR: *** cfgtrace: c=[/home/spider/work/sip/esr/sip-router/../etc/kamailio-3.1-debugger.cfg] l=370 a=3 n=drop 11(30316) DEBUG: tm [t_funcs.c:361]: ERROR:tm:t_relay_to: t_forward_nonack returned error 11(30316) DEBUG: tm [t_funcs.c:369]: -6 error reply generation delayed 11(30316) ERROR: *** cfgtrace: c=[/home/spider/work/sip/esr/sip-router/../etc/kamailio-3.1-debugger.cfg] l=386 a=3 n=exit 11(30316) DEBUG: tm [t_lookup.c:1532]: t_unref: delayed error reply generation(-6) 11(30316) DEBUG: <core> [msg_translator.c:207]: check_via_address(192.168.56.102, 192.168.56.102, 0) 11(30316) DEBUG: tm [t_reply.c:1464]: DEBUG: cleanup_uac_timers: RETR/FR timers reset 11(30316) DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb596b1d0, callback type 128, id 0 entered 11(30316) NOTICE: acc [acc.c:275]: ACC: call missed: timestamp=1292662280;method=INVITE;from_tag=500B2B26;to_tag=;call_id=1182353533@192.168.56.102;code=500;reason=Server Internal Error;src_user=102;src_domain=192.168.56.102;dst_ouser=123;ruri=sip:123@192.168.56.102;dst_user=123;dst_domain=192.168.56.102 11(30316) DEBUG: tm [t_reply.c:659]: DEBUG: reply sent out. buf=0x830422c: SIP/2.0 500 I'm terr..., shmem=0xb596c89c: SIP/2.0 500 I'm terr 11(30316) DEBUG: tm [t_reply.c:669]: DEBUG: _reply_light: finished
I was wondering where you get 503 reply code since I get 500. I do log_extra instead of db_extra, but fetching of the values is the same thing.
Cheers, Daniel
Daniel-Constantin Mierla writes:
I was wondering where you get 503 reply code since I get 500. I do log_extra instead of db_extra, but fetching of the values is the same thing.
503 is generated from my script when there is no more gateways available:
while ($true) { if (!next_gw()) { send_reply("503", "Service not available"); exit; }; t_on_branch("BRANCHES"); if (t_relay()) exit; };
-- juha
still cannot reproduce it, so better work on your core file.
Looks like the r-uri gets corrupted, send the output of:
frame 1 print *msg
Daniel
On 12/18/10 10:10 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I was wondering where you get 503 reply code since I get 500. I do log_extra instead of db_extra, but fetching of the values is the same thing.
503 is generated from my script when there is no more gateways available:
while ($true) { if (!next_gw()) { send_reply("503", "Service not available"); exit; }; t_on_branch("BRANCHES"); if (t_relay()) exit; };-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
Looks like the r-uri gets corrupted, send the output of:
next_gw() rewrite $ru like this:
/* Rewrite Request URI */ uri_str.s = r_uri; uri_str.len = r_uri_len; rewrite_uri(_m, &uri_str);
frame 1 print *msg
i'll send that to you privately.
-- juha
I did a commit, please try to see if it is fixed now. Somehow, accounting of missed call event used a different uri discovery scheme than normal accounting even for failed transactions (which is practically same event).
If works, we can backport - affected case was as you discovered, when there was drop called and branch not forwarded with missed call acc flag set.
Cheers, Daniel
On 12/19/10 11:01 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Looks like the r-uri gets corrupted, send the output of:
next_gw() rewrite $ru like this:
/* Rewrite Request URI */ uri_str.s = r_uri; uri_str.len = r_uri_len; rewrite_uri(_m,&uri_str);frame 1 print *msg
i'll send that to you privately.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel-Constantin Mierla -
Juha Heinanen