16 Dec
2010
16 Dec
'10
8:15 p.m.
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
16 Dec
16 Dec
8:30 p.m.
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
17 Dec
17 Dec
9:10 a.m.
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.
-- juha
18 Dec
18 Dec
10:18 a.m.
On 12/17/10 8:10 AM, Juha Heinanen wrote:
Juha Heinanen 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
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
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
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.
10:34 a.m.
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
11 a.m.
On 12/18/10 9:34 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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(a)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
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
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.
11:10 a.m.
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
19 Dec
19 Dec
11:57 a.m.
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:
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:01 p.m.
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
1:03 p.m.
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:
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
5090
days inactive
5093
days old
10 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen