[SR-Users] possible bug with dialog module
Kelvin Chua
kelchy at gmail.com
Thu Apr 22 12:00:21 CEST 2010
(gdb) print buf+300
$2 = 0x869fec "65\r\nCall-ID:
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"...
(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 at 10.17.0.200 <ip%3A3701 at 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 at 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 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"<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%5Cr%5Cn%5Cr%5Cn>,
> 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"<sip:029147089 at 10.17.0.200sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
> 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"<sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
> len = 19},
> req_uri = {s = 0x2ab61c910290 "sip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n"<sip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
> len = 50}, tag = {{
> s = 0x2ab61c91c488 "as50d7852dsip:029147089 at 10.17.0.200<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<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 <sip%3A029147089 at 10.17.0.200>>;tag=as50d7852d\r\nTo:
> <sip:4153 at hiddendomain.edu <sip%3A4153 at hiddendomain.edu>>;tag=4735210"...
>
>
>
> (gdb) print buf+200
> $4 = 0x869f88 "\nFrom: \"029147089\" <sip:029147089 at 10.17.0.200<sip%3A029147089 at 10.17.0.200>>;tag=as50d7852d\r\nTo:
> <sip:4153 at hiddendomain.edu <sip%3A4153 at hiddendomain.edu>>;tag=473521065\r\nCall-ID:
> 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\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> 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> 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>wrote:
>>>
>>>> 2010/4/21 Kelvin Chua <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>
>>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100422/cb2dfc61/attachment.htm>
More information about the sr-users
mailing list