[SR-Users] possible bug with dialog module
Daniel-Constantin Mierla
miconda at gmail.com
Thu Apr 22 10:49:39 CEST 2010
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 at 10.17.0.200sip:029147089 at 10.17.0.200sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n", len = 44}, from_uri = {
> s = 0x2ab61c910264
> "sip:029147089 at 10.17.0.200sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n", len = 25}, to_uri = {
> s = 0x2ab61c91027d
> "sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n", len = 19},
> req_uri = {s = 0x2ab61c910290
> "sip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n", len = 50}, tag = {{
> s = 0x2ab61c91c488 "as50d7852dsip:029147089 at 10.17.0.200
> <mailto:as50d7852dsip%3A029147089 at 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 at 10.17.0.200
> <mailto:sip%3A029147089 at 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 at 10.17.0.200
> <mailto:sip%3A029147089 at 10.17.0.200>>;tag=as50d7852d\r\nTo:
> <sip:4153 at hiddendomain.edu
> <mailto:sip%3A4153 at hiddendomain.edu>>;tag=4735210"...
>
>
>
> (gdb) print buf+200
> $4 = 0x869f88 "\nFrom: \"029147089\" <sip:029147089 at 10.17.0.200
> <mailto:sip%3A029147089 at 10.17.0.200>>;tag=as50d7852d\r\nTo:
> <sip:4153 at hiddendomain.edu
> <mailto:sip%3A4153 at hiddendomain.edu>>;tag=473521065\r\nCall-ID:
> 0901b21e13a60e0247988caf7d72f865 at 10.17.0.200
> <mailto:0901b21e13a60e0247988caf7d72f865 at 10.17.0.200>\r\nCSeq: 102
> INVITE\r\nServer: Cisco ATA 186 "...
>
>
>
> (gdb) print buf+300
> $5 = 0x869fec "65\r\nCall-ID:
> 0901b21e13a60e0247988caf7d72f865 at 10.17.0.200
> <mailto:0901b21e13a60e0247988caf7d72f865 at 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 at gmail.com <mailto:miconda at 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 at gmail.com <mailto:miconda at 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 at aliax.net <mailto:ibc at aliax.net>> wrote:
>>>
>>> 2010/4/21 Kelvin Chua <kelchy at gmail.com
>>> <mailto:kelchy at 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 at aliax.net <mailto:ibc at aliax.net>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> <mailto:sr-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100422/cfb9dafc/attachment.htm>
More information about the sr-users
mailing list