22 Apr
2010
22 Apr
'10
4:49 a.m.
Hi,
if you still have the core file, can you print more of buffer until it
gets to end of headers? I am curios to see what is wrong with the contact.
Just increase by 100:
(gdb) print buf+300
(gdb) print buf+400
...
Thanks,
Daniel
On 4/21/10 3:15 PM, Kelvin Chua wrote:
(gdb) bt
#0 0x00002ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8)
at dlg_db_handler.c:501
#1 0x00002ab61b628ea8 in dlg_onreply (t=0x7d5228, type=<value
optimized out>, param=<value optimized out>) at dlg_handlers.c:361
#2 0x00002ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
params=0x7fffec157970) at t_hooks.c:261
#3 0x00002ab61796575e in run_trans_callbacks (type=1, trans=0x88c580,
req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4 0x00002ab61798ebd1 in relay_reply (t=0x2ab61c9387c0, p_msg=<value
optimized out>, branch=0, msg_status=200,
cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5 0x00002ab617990884 in reply_received (p_msg=0x8f48a8) at
t_reply.c:2126
#6 0x000000000044760e in forward_reply (msg=0x8f48a8) at forward.c:689
#7 0x000000000047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
<sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r"..., len=<value optimized
out>,
rcv_info=0x7fffec158020) at receive.c:257
#8 0x0000000000505e2b in udp_rcv_loop () at udp_server.c:520
#9 0x0000000000455adf in main_loop () at main.c:1447
#10 0x0000000000456be2 in main (argc=<value optimized out>,
argv=0x7fffec1582e8) at main.c:2251
(gdb) print cell
$1 = (struct dlg_cell *) 0x2ab61c9100f8
(gdb) print *cell
$2 = {ref = 2, next = 0x0, prev = 0x0, h_id = 996587990, h_entry =
1420, state = 3, lifetime = 3600, start_ts = 1271816397,
dflags = 1, sflags = 0, toroute = 0, from_rr_nb = 0, tl = {next =
0x0, prev = 0x0, timeout = 0}, callid = {
s = 0x2ab61c910238
"0901b21e13a60e0247988caf7d72f865@10.17.0.200sip:029147089@10.17.0.200sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 44}, from_uri = {
s = 0x2ab61c910264
"sip:029147089@10.17.0.200sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 25}, to_uri = {
s = 0x2ab61c91027d
"sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 19},
req_uri = {s = 0x2ab61c910290
"sip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 50}, tag = {{
s = 0x2ab61c91c488 "as50d7852dsip:029147089@10.17.0.200
<mailto:as50d7852dsip%3A029147089@10.17.0.200>\034�*", len = 10}, {s =
0x0, len = 0}}, cseq = {{
s = 0x2ab61c857950 "10213331\b", len = 3}, {s = 0x0, len = 0}},
route_set = {{s = 0x0, len = 0}, {s = 0x0, len = 0}},
contact = {{s = 0x2ab61c91c492 "sip:029147089@10.17.0.200
<mailto:sip%3A029147089@10.17.0.200>\034�*", len = 25}, {s = 0x0, len
= 0}}, bind_addr = {0x88c580, 0x0},
cbs = {first = 0x0, types = 0}, profile_links = 0x0}
(gdb) frame 7
#7 0x000000000047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
<sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r"..., len=<value optimized
out>,
rcv_info=0x7fffec158020) at receive.c:257
257 forward_reply(msg);
(gdb) print buf+100
$3 = 0x869f24
".200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
<sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r\nFrom: \"029147089\"
<sip:029147089@10.17.0.200
<mailto:sip%3A029147089@10.17.0.200>>;tag=as50d7852d\r\nTo:
<sip:4153@hiddendomain.edu
<mailto:sip%3A4153@hiddendomain.edu>>;tag=4735210"...
(gdb) print buf+200
$4 = 0x869f88 "\nFrom: \"029147089\" <sip:029147089@10.17.0.200
<mailto:sip%3A029147089@10.17.0.200>>;tag=as50d7852d\r\nTo:
<sip:4153@hiddendomain.edu
<mailto:sip%3A4153@hiddendomain.edu>>;tag=473521065\r\nCall-ID:
0901b21e13a60e0247988caf7d72f865(a)10.17.0.200
<mailto:0901b21e13a60e0247988caf7d72f865@10.17.0.200>\r\nCSeq: 102
INVITE\r\nServer: Cisco ATA 186 "...
(gdb) print buf+300
$5 = 0x869fec "65\r\nCall-ID:
0901b21e13a60e0247988caf7d72f865(a)10.17.0.200
<mailto:0901b21e13a60e0247988caf7d72f865@10.17.0.200>\r\nCSeq: 102
INVITE\r\nServer: Cisco ATA 186 v3.2.0 atasip (041111A)\r\nAllow:
ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, U"...
Kelvin Chua
On Wed, Apr 21, 2010 at 7:22 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 4/21/10 12:23 PM, Kelvin Chua wrote:
--
Daniel-Constantin Mierla * http://www.asipto.com/ *
http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla
hi daniel,
i'm not using git version. so maybe i'm missing some patches. can
you confirm if what i am
experiencing is the same problem and the fix is indeed available
from the git version? thanks
I recommend using at least 3.0.1, as a matter of fact 3.0.2 should
be released soon.
Can you please print the content of cell adn more of the reply in
gdb, here are the commands:
gdb /path/to/kamailio core_file
print cell
print *cell
frame 7
print buf+100
print buf+200
print buf+300
Thanks,
Daniel
here is the backtrace:
#0 0x00002ab61b62779a in update_dialog_dbinfo
(cell=0x2ab61c9100f8) at dlg_db_handler.c:501
#1 0x00002ab61b628ea8 in dlg_onreply (t=0x7d5228, type=<value
optimized out>, param=<value optimized out>) at dlg_handlers.c:361
#2 0x00002ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
params=0x7fffec157970) at t_hooks.c:261
#3 0x00002ab61796575e in run_trans_callbacks (type=1,
trans=0x88c580, req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4 0x00002ab61798ebd1 in relay_reply (t=0x2ab61c9387c0,
p_msg=<value optimized out>, branch=0, msg_status=200,
cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5 0x00002ab617990884 in reply_received (p_msg=0x8f48a8) at
t_reply.c:2126
#6 0x000000000044760e in forward_reply (msg=0x8f48a8) at
forward.c:689
#7 0x000000000047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
<sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r"..., len=<value
optimized out>,
rcv_info=0x7fffec158020) at receive.c:257
#8 0x0000000000505e2b in udp_rcv_loop () at udp_server.c:520
#9 0x0000000000455adf in main_loop () at main.c:1447
#10 0x0000000000456be2 in main (argc=<value optimized out>,
argv=0x7fffec1582e8) at main.c:2251
Kelvin Chua
On Wed, Apr 21, 2010 at 6:04 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
are you using the latest git version of branch kamailio_3.0?
It was a fix to dialog after the 3.0.0 release, adding some
sanity checks for broken messages:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb…
On the other hand, I see you got a core dump file:
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]:
ALERT: <core> [main.c:722]: child process 28511 exited by a
signal 11
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]:
ALERT: <core> [main.c:725]: core was generated
Locate the core file and sent the backtrace. The core is
either in root '/' folder or in working directory (if you
provided by -w parameter).
Use the gdb:
gdb /path/to/kamailio core_file
then do bt and send here.
Thanks,
Daniel
On 4/21/10 11:38 AM, Kelvin Chua wrote:
--
Daniel-Constantin Mierla * http://www.asipto.com/ *
http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla
ok, i'll enable debug for now.
but if it's indeed a buggy UA, the dialog module should not
have crashed
but instead dropped the dialog/session and moved on,
something i think
we need to address to be more resilient.
i hope i catch the culprit when this happens again.
Kelvin Chua
On Wed, Apr 21, 2010 at 5:33 PM, Iñaki Baz Castillo
<ibc(a)aliax.net <mailto:ibc@aliax.net>> wrote:
2010/4/21 Kelvin Chua <kelchy(a)gmail.com
<mailto:kelchy@gmail.com>>:
--
Daniel-Constantin Mierla * http://www.asipto.com/ *
http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla
i wonder if anybody from list is also
experiencing this?
Perhaps in your case you have a buggy UA setting an
invalid Contact
header and it causes Kamailio to crash, maybe the reason
others have
not detected same issue.
Could you get some SIP traces until the problem occurs
again?
or perhaps could you enable the debug?
--
Iñaki Baz Castillo
<ibc(a)aliax.net <mailto:ibc@aliax.net>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users