currently using kamailio 3.0 with around 1000 users.
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at 0000000000000088 rip 00002ab61b62779a rsp 00007fffec157440 error 4 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
Kelvin Chua
2010/4/21 Kelvin Chua kelchy@gmail.com:
currently using kamailio 3.0 with around 1000 users. Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at 0000000000000088 rip 00002ab61b62779a rsp 00007fffec157440 error 4 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
Oh my god! Let me two question:
- Are you able to determine if the problem occurs when handling an INVITE or a response? - Do you know if some occurs in Kamailio 1.5?
hi inaki,
unfortunately since i am not expecting any segfaults from kamailio, i have very little debug info, only those spurted out by syslog. not been using 1.5 for some time now.
bad news, happened twice today. in a span of 3 hours. seems like an inbound BYE. here is the other instance:
Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: WARNING: dialog [dlg_handlers.c:806]: unable to find dialog for BYE with route param 'e34.a5ceb3d5' [1086:1564208218] Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 11:58:56 kamvm-1 kernel: kamailio[2526]: segfault at 0000000000000088 rip 00002b4a039f979a rsp 00007fff0f0472c0 error 4 Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: <core> [main.c:722]: child process 2526 exited by a signal 11 Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: <core> [main.c:725]: core was generated
Kelvin Chua
On Wed, Apr 21, 2010 at 5:06 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
currently using kamailio 3.0 with around 1000 users. Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at 0000000000000088 rip 00002ab61b62779a rsp 00007fffec157440 error 4 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
Oh my god! Let me two question:
- Are you able to determine if the problem occurs when handling an
INVITE or a response?
- Do you know if some occurs in Kamailio 1.5?
-- Iñaki Baz Castillo ibc@aliax.net
2010/4/21 Kelvin Chua kelchy@gmail.com:
hi inaki, unfortunately since i am not expecting any segfaults from kamailio, i have very little debug info, only those spurted out by syslog. not been using 1.5 for some time now. bad news, happened twice today. in a span of 3 hours. seems like an inbound BYE. here is the other instance:
Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: WARNING: dialog [dlg_handlers.c:806]: unable to find dialog for BYE with route param 'e34.a5ceb3d5' [1086:1564208218]
This just means that Kamailio has received a BYE thtat doesn't match with an existing dialog. Perhaps the dialog expired, a previous BYE from the other side was already received or kamailio was restarted and doesn't keep the dialogs info in database.
Are you sure that the folowing log lines occur due to the previous BYE line? has the server lot of traffic?
Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 11:58:56 kamvm-1 kernel: kamailio[2526]: segfault at 0000000000000088 rip 00002b4a039f979a rsp 00007fff0f0472c0 error 4 Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: <core> [main.c:722]: child process 2526 exited by a signal 11 Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: <core> [main.c:725]: core was generated
Kelvin Chua
On Wed, Apr 21, 2010 at 5:06 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
currently using kamailio 3.0 with around 1000 users. Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at 0000000000000088 rip 00002ab61b62779a rsp 00007fffec157440 error 4 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
Oh my god! Let me two question:
- Are you able to determine if the problem occurs when handling an
INVITE or a response?
- Do you know if some occurs in Kamailio 1.5?
-- Iñaki Baz Castillo ibc@aliax.net
yeah lots of traffic. so there's no way of telling whether that particular BYE caused the crashed or not. unless i enable debug for the server.
besides, you're right it might just be a simple case of receiving a BYE for an expired dialog or something, doesn't seem too fishy at all. i wonder if anybody from the list is also experiencing this?
Kelvin Chua
On Wed, Apr 21, 2010 at 5:16 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
hi inaki, unfortunately since i am not expecting any segfaults from kamailio, i
have
very little debug info, only those spurted out by syslog. not been using 1.5 for some time now. bad news, happened twice today. in a span of 3 hours. seems like an inbound BYE. here is the other instance:
Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: WARNING: dialog [dlg_handlers.c:806]: unable to find dialog for BYE with route param 'e34.a5ceb3d5' [1086:1564208218]
This just means that Kamailio has received a BYE thtat doesn't match with an existing dialog. Perhaps the dialog expired, a previous BYE from the other side was already received or kamailio was restarted and doesn't keep the dialogs info in database.
Are you sure that the folowing log lines occur due to the previous BYE line? has the server lot of traffic?
Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 11:58:56 kamvm-1 kernel: kamailio[2526]: segfault at
0000000000000088
rip 00002b4a039f979a rsp 00007fff0f0472c0 error 4 Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: <core> [main.c:722]: child process 2526 exited by a signal 11 Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: <core> [main.c:725]: core was generated
Kelvin Chua
On Wed, Apr 21, 2010 at 5:06 PM, Iñaki Baz Castillo ibc@aliax.net
wrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
currently using kamailio 3.0 with around 1000 users. Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:218]: bad sip message or missing Contact hdr Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog [dlg_handlers.c:350]: could not add further info to the dialog Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at 0000000000000088 rip 00002ab61b62779a rsp 00007fffec157440 error 4 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
Oh my god! Let me two question:
- Are you able to determine if the problem occurs when handling an
INVITE or a response?
- Do you know if some occurs in Kamailio 1.5?
-- Iñaki Baz Castillo ibc@aliax.net
-- Iñaki Baz Castillo ibc@aliax.net
2010/4/21 Kelvin Chua kelchy@gmail.com:
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?
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@aliax.net wrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
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@aliax.net
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=787fabb1...
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:
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@aliax.net mailto:ibc@aliax.net> wrote:
2010/4/21 Kelvin Chua <kelchy@gmail.com <mailto:kelchy@gmail.com>>: > 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@aliax.net <mailto:ibc@aliax.net>>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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@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=787fabb1...
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:
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@aliax.net wrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
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@aliax.net
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
Hello,
On 4/21/10 12:23 PM, Kelvin Chua wrote:
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@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=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c 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: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@aliax.net <mailto:ibc@aliax.net>> wrote: 2010/4/21 Kelvin Chua <kelchy@gmail.com <mailto:kelchy@gmail.com>>: > 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@aliax.net <mailto:ibc@aliax.net>> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
(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.200as50d7852dsip%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.200sip%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 sip%3A029147089@10.17.0.200>;tag=as50d7852d\r\nTo: <sip:4153@hiddendomain.edu sip%3A4153@hiddendomain.edu>;tag=4735210"...
(gdb) print buf+200 $4 = 0x869f88 "\nFrom: "029147089" <sip:029147089@10.17.0.200sip%3A029147089@10.17.0.200>;tag=as50d7852d\r\nTo: <sip:4153@hiddendomain.edu sip%3A4153@hiddendomain.edu>;tag=473521065\r\nCall-ID: 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@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@gmail.com
wrote:
Hello,
On 4/21/10 12:23 PM, Kelvin Chua wrote:
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@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=787fabb1...
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:
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@aliax.netwrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
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@aliax.net
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
Hello,
Kelvin Chua wrote:
(gdb) bt #0 0x00002ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at dlg_db_handler.c:501
This corresponds to
SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str);
so assumingly sip-router crashes when it tries to access the callee's bound address's sock_str...
#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,
(gdb) print cell $1 = (struct dlg_cell *) 0x2ab61c9100f8
(gdb) print *cell 0}}, bind_addr = {0x88c580, 0x0}, cbs = {first = 0x0, types = 0}, profile_links = 0x0}
... as supported by the fact that bind_addr's second field (DLG_CALLEE_LEG) is 0.
Why does the segfault happen?
Let's trace the code path: The initial error message
"bad sip message or missing Contact hdr"
occurred in dlg_handlers.c, line 218, which makes this piece of code's surrounding function "populate_leg_info" return prematurely (by means of "goto error0"). Specifically, this implies that the code at the end of the function on line 272
dlg->bind_addr[leg] = msg->rcv.bind_address;
isn't carried out anymore, leaving the callee's bound address associated with the given dialog unassigned. (This happens to be the only occasion where the bound address is assigned.) Instead, execution drops back to the "dlg_onreply" function and proceeds to line 361, thereby calling the database update function:
update_dialog_dbinfo(dlg);
which directly leads to the segfaulting code location.
AFAICS, "update_dialog_dbinfo" is dereferencing a possibly null memory location at the dialog data in question only, so one way to prevent the segfault from happening is to move the bound address assignment before any failing code in the function. This should make sure that some accessible bound address is stored in any case.
Cheers,
--Timo
Hi Timo,
thanks for troubleshooting. I committed the patch that moves setting of bind_addr before any error case in populate_leg_info(). I backported to kamailio_3.0 branch as well.
Kelvin, can you get the lasted git version for branch kamailio_3.0 and test?
Thanks, Daniel
On 4/22/10 1:21 AM, Timo Reimann wrote:
Hello,
Kelvin Chua wrote:
(gdb) bt #0 0x00002ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at dlg_db_handler.c:501
This corresponds to
SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str);
so assumingly sip-router crashes when it tries to access the callee's bound address's sock_str...
#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,
(gdb) print cell $1 = (struct dlg_cell *) 0x2ab61c9100f8
(gdb) print *cell 0}}, bind_addr = {0x88c580, 0x0}, cbs = {first = 0x0, types = 0}, profile_links = 0x0}
... as supported by the fact that bind_addr's second field (DLG_CALLEE_LEG) is 0.
Why does the segfault happen?
Let's trace the code path: The initial error message
"bad sip message or missing Contact hdr"
occurred in dlg_handlers.c, line 218, which makes this piece of code's surrounding function "populate_leg_info" return prematurely (by means of "goto error0"). Specifically, this implies that the code at the end of the function on line 272
dlg->bind_addr[leg] = msg->rcv.bind_address;
isn't carried out anymore, leaving the callee's bound address associated with the given dialog unassigned. (This happens to be the only occasion where the bound address is assigned.) Instead, execution drops back to the "dlg_onreply" function and proceeds to line 361, thereby calling the database update function:
update_dialog_dbinfo(dlg);
which directly leads to the segfaulting code location.
AFAICS, "update_dialog_dbinfo" is dereferencing a possibly null memory location at the dialog data in question only, so one way to prevent the segfault from happening is to move the bound address assignment before any failing code in the function. This should make sure that some accessible bound address is stored in any case.
Cheers,
--Timo
Hey Daniel,
Daniel-Constantin Mierla wrote:
thanks for troubleshooting. I committed the patch that moves setting of bind_addr before any error case in populate_leg_info(). I backported to kamailio_3.0 branch as well.
Kelvin, can you get the lasted git version for branch kamailio_3.0 and test?
Thanks Daniel. What about applying the bugfix to Kamailio 1.5 (and maybe even 1.[43]) too? I see that 1.5 is less ambitious to "goto error0" and thereby skip the assignment but it may still happen (for instance, if CSeq parsing fails). 1.[43]'s "populate_leg_info" function look more similar to 3.0's and may definitely crash as well.
And if we decide to backport the patch: Shall we wait for Kelvin to test the 3.0 patch first to make sure it really works?
Cheers,
--Timo
these Cisco ATAs are so old, we are maintaining around 300 of these, and a lot of times we encounter corrupted SIP messages of which some are fixed by just reboots, other times, by upgrading firmwares.
most of the times, kamailio manages to stay afloat in the midst of all these corruption except for some instances like the one i'm reporting, it didn't.
i am currently getting the latest git and will test. the last crash we encountered before yesterday is march 30 and before that, january 5. if i manage to upgrade this now, we won't know if it really works not unless we monitor this for at least 3 months :-)
Kelvin Chua
On Thu, Apr 22, 2010 at 4:47 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hi Timo,
thanks for troubleshooting. I committed the patch that moves setting of bind_addr before any error case in populate_leg_info(). I backported to kamailio_3.0 branch as well.
Kelvin, can you get the lasted git version for branch kamailio_3.0 and test?
Thanks, Daniel
On 4/22/10 1:21 AM, Timo Reimann wrote:
Hello,
Kelvin Chua wrote:
(gdb) bt #0 0x00002ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at dlg_db_handler.c:501
This corresponds to
SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str);
so assumingly sip-router crashes when it tries to access the callee's bound address's sock_str...
#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,
(gdb) print cell $1 = (struct dlg_cell *) 0x2ab61c9100f8
(gdb) print *cell 0}}, bind_addr = {0x88c580, 0x0}, cbs = {first = 0x0, types = 0}, profile_links = 0x0}
... as supported by the fact that bind_addr's second field (DLG_CALLEE_LEG) is 0.
Why does the segfault happen?
Let's trace the code path: The initial error message
"bad sip message or missing Contact hdr"
occurred in dlg_handlers.c, line 218, which makes this piece of code's surrounding function "populate_leg_info" return prematurely (by means of "goto error0"). Specifically, this implies that the code at the end of the function on line 272
dlg->bind_addr[leg] = msg->rcv.bind_address;
isn't carried out anymore, leaving the callee's bound address associated with the given dialog unassigned. (This happens to be the only occasion where the bound address is assigned.) Instead, execution drops back to the "dlg_onreply" function and proceeds to line 361, thereby calling the database update function:
update_dialog_dbinfo(dlg);
which directly leads to the segfaulting code location.
AFAICS, "update_dialog_dbinfo" is dereferencing a possibly null memory location at the dialog data in question only, so one way to prevent the segfault from happening is to move the bound address assignment before any failing code in the function. This should make sure that some accessible bound address is stored in any case.
Cheers,
--Timo
-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
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@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@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@gmail.com mailto:miconda@gmail.com> wrote:
Hello, On 4/21/10 12:23 PM, Kelvin Chua wrote: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? thanksI 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, Danielhere 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@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=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c 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: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@aliax.net <mailto:ibc@aliax.net>> wrote: 2010/4/21 Kelvin Chua <kelchy@gmail.com <mailto:kelchy@gmail.com>>: > 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@aliax.net <mailto:ibc@aliax.net>> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
(gdb) print buf+300 $2 = 0x869fec "65\r\nCall-ID: 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"...
(gdb) print buf+400 $1 = 0x86a050 "v3.2.0 atasip (041111A)\r\nAllow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+500 $4 = 0x86a0b4 "PDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+600 $5 = 0x86a118 "ip:3701@10.17.0.200 ip%3A3701@10.17.0.200>\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+700 $6 = 0x86a17c "A/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"
(gdb) print buf+800 $7 = 0x86a1e0 "p:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"
(gdb) print buf+900 $8 = 0x86a244 "8000\r\na=fmtp:101 0-16,32-36,54\r\na=silenceSupp:off - - - -\r\n"
(gdb) print buf+1000 $9 = 0x86a2a8 "0\r\na=fmtp:101 0-15\r\n"
(gdb) print buf+1100 $10 = 0x86a30c "000\r\na=ptime:20\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:4 G723/8000\r\na=rtpmap:18 G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 AAL2-G726-1"...
(gdb) print buf+1200 $11 = 0x86a370 "32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"
(gdb) print buf+1300 $12 = 0x86a3d4 "6/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"
(gdb) print buf+1400 $13 = 0x86a438 ""
(gdb) print buf+1500 $14 = 0x86a49c "5395257"\r\nContent-Length: 0\r\n\r\n"
Kelvin Chua
On Thu, Apr 22, 2010 at 4:49 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
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"<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%5Cr%5Cn%5Cr%5Cn>, 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"sip:029147089@10.17.0.200sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn, 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"sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn, len = 19}, req_uri = {s = 0x2ab61c910290 "sip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length: 0\r\n\r\n"sip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn, len = 50}, tag = {{ s = 0x2ab61c91c488 "as50d7852dsip:029147089@10.17.0.200as50d7852dsip%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.200sip%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 sip%3A029147089@10.17.0.200>;tag=as50d7852d\r\nTo: <sip:4153@hiddendomain.edu sip%3A4153@hiddendomain.edu>;tag=4735210"...
(gdb) print buf+200 $4 = 0x869f88 "\nFrom: "029147089" <sip:029147089@10.17.0.200sip%3A029147089@10.17.0.200>;tag=as50d7852d\r\nTo: <sip:4153@hiddendomain.edu sip%3A4153@hiddendomain.edu>;tag=473521065\r\nCall-ID: 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@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@gmail.com> wrote:
Hello,
On 4/21/10 12:23 PM, Kelvin Chua wrote:
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@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=787fabb1...
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:
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@aliax.netwrote:
2010/4/21 Kelvin Chua kelchy@gmail.com:
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@aliax.net
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
Hello,
thanks, so the Contact header is missing, that makes the 200ok invalid for invitate - afaik contact is mandatory. Anyhow, crash should not happen, but I wonder what happens with such call, practically the caller does not know where to send the BYE. Or maybe 18x reply has contact hdr and that is used ...
Cheers, Daniel
On 4/22/10 12:00 PM, Kelvin Chua wrote:
(gdb) print buf+300 $2 = 0x869fec "65\r\nCall-ID: 0901b21e13a60e0247988caf7d72f865@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"...
(gdb) print buf+400 $1 = 0x86a050 "v3.2.0 atasip (041111A)\r\nAllow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+500 $4 = 0x86a0b4 "PDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+600 $5 = 0x86a118 "ip:3701@10.17.0.200 mailto:ip%3A3701@10.17.0.200>\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+700 $6 = 0x86a17c "A/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"
(gdb) print buf+800 $7 = 0x86a1e0 "p:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"
(gdb) print buf+900 $8 = 0x86a244 "8000\r\na=fmtp:101 0-16,32-36,54\r\na=silenceSupp:off -
- -\r\n"
(gdb) print buf+1000 $9 = 0x86a2a8 "0\r\na=fmtp:101 0-15\r\n"
(gdb) print buf+1100 $10 = 0x86a30c "000\r\na=ptime:20\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:4 G723/8000\r\na=rtpmap:18 G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 AAL2-G726-1"...
(gdb) print buf+1200 $11 = 0x86a370 "32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"
(gdb) print buf+1300 $12 = 0x86a3d4 "6/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"
(gdb) print buf+1400 $13 = 0x86a438 ""
(gdb) print buf+1500 $14 = 0x86a49c "5395257"\r\nContent-Length: 0\r\n\r\n"
Kelvin Chua
On Thu, Apr 22, 2010 at 4:49 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
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" <mailto: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%5Cr%5Cn%5Cr%5Cn>, 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" <mailto:sip:029147089@10.17.0.200sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>, 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" <mailto:sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>, len = 19}, req_uri = {s = 0x2ab61c910290 "sip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length: 0\r\n\r\n" <mailto:sip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>, 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@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@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@gmail.com <mailto:miconda@gmail.com>> wrote: Hello, On 4/21/10 12:23 PM, Kelvin Chua wrote: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? thanksI 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, Danielhere 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@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=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c 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: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@aliax.net <mailto:ibc@aliax.net>> wrote: 2010/4/21 Kelvin Chua <kelchy@gmail.com <mailto:kelchy@gmail.com>>: > 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@aliax.net <mailto:ibc@aliax.net>> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
thanks, so the Contact header is missing, that makes the 200ok invalid for invitate - afaik contact is mandatory. Anyhow, crash should not happen, but I wonder what happens with such call, practically the caller does not know where to send the BYE. Or maybe 18x reply has contact hdr and that is used ...
Cheers, Daniel
On 4/22/10 12:00 PM, Kelvin Chua wrote:
(gdb) print buf+300 $2 = 0x869fec "65\r\nCall-ID: 0901b21e13a60e0247988caf7d72f865@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"...
(gdb) print buf+400 $1 = 0x86a050 "v3.2.0 atasip (041111A)\r\nAllow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+500 $4 = 0x86a0b4 "PDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+600 $5 = 0x86a118 "ip:3701@10.17.0.200 mailto:ip%3A3701@10.17.0.200>\r\nContent-Length: 0\r\n\r\n"
(gdb) print buf+700 $6 = 0x86a17c "A/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"
(gdb) print buf+800 $7 = 0x86a1e0 "p:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"
(gdb) print buf+900 $8 = 0x86a244 "8000\r\na=fmtp:101 0-16,32-36,54\r\na=silenceSupp:off -
- -\r\n"
(gdb) print buf+1000 $9 = 0x86a2a8 "0\r\na=fmtp:101 0-15\r\n"
(gdb) print buf+1100 $10 = 0x86a30c "000\r\na=ptime:20\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:4 G723/8000\r\na=rtpmap:18 G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 AAL2-G726-1"...
(gdb) print buf+1200 $11 = 0x86a370 "32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"
(gdb) print buf+1300 $12 = 0x86a3d4 "6/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"
(gdb) print buf+1400 $13 = 0x86a438 ""
(gdb) print buf+1500 $14 = 0x86a49c "5395257"\r\nContent-Length: 0\r\n\r\n"
Kelvin Chua
On Thu, Apr 22, 2010 at 4:49 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
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" <mailto: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%5Cr%5Cn%5Cr%5Cn>, 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" <mailto:sip:029147089@10.17.0.200sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>, 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" <mailto:sip:4153@hiddendomain.edusip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>, len = 19}, req_uri = {s = 0x2ab61c910290 "sip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length: 0\r\n\r\n" <mailto:sip:4153@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>, 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@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@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@gmail.com <mailto:miconda@gmail.com>> wrote: Hello, On 4/21/10 12:23 PM, Kelvin Chua wrote: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? thanksI 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, Danielhere 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@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=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c 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: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@aliax.net <mailto:ibc@aliax.net>> wrote: 2010/4/21 Kelvin Chua <kelchy@gmail.com <mailto:kelchy@gmail.com>>: > 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@aliax.net <mailto:ibc@aliax.net>> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla-- Daniel-Constantin Mierla * http://www.asipto.com/ * http://twitter.com/miconda * http://www.linkedin.com/in/danielconstantinmierla
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/4/21 Daniel-Constantin Mierla miconda@gmail.com:
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=787fabb1...
Hi Daniel, these changes are already present in Kamailio 1.5 branch, right?
On 4/21/10 1:31 PM, Iñaki Baz Castillo wrote:
2010/4/21 Daniel-Constantin Mierlamiconda@gmail.com:
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=787fabb1...
Hi Daniel, these changes are already present in Kamailio 1.5 branch, right?
yes, they are.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Kelvin Chua -
Timo Reimann