But, sometimes I get this crash (in the same scenario as below), too:
(gdb) where #0 0x000000000055e602 in free_to_params (tb=0x7f95ab472950) at parser/parse_to.c:827 #1 0x000000000055e658 in free_to (tb=0x7f95ab472950) at parser/parse_to.c:838 #2 0x000000000053e2a9 in clean_hdr_field (hf=0x7f95ab4722a0) at parser/hf.c:113 #3 0x000000000053e51d in free_hdr_field_lst (hf=0x7f95ab46f1c0) at parser/hf.c:223 #4 0x0000000000542d04 in free_sip_msg (msg=0x7f95ab471970) at parser/msg_parser.c:729 #5 0x000000000049e39d in receive_msg ( buf=0x9065c0 "SIP/2.0 404 Not Found\r\nVia: SIP/2.0/UDP 55.177.31.199;branch=z9hG4bKa744.4c8811f1.0\r\nVia: SIP/2.0/UDP 68.68.120.41:5060;branch=z9hG4bK02B15f46caff804796d\r\nRecord-Route: <sip:55.177.31.199;lr=on;ftag=g"..., len=715, rcv_info=0x7fff05e5dbc0) at receive.c:296 #6 0x000000000052ffa1 in udp_rcv_loop () at udp_server.c:557 #7 0x0000000000467de2 in main_loop () at main.c:1638 #8 0x000000000046ad8b in main (argc=13, argv=0x7fff05e5def8) at main.c:2566
-- Alex
On 09/05/2013 06:25 AM, Alex Balashov wrote:
I've managed to reproduce this scenario in a more general case. Even when I disable my "problematic" route sequence, a 404 Not Found response from this same PBX causes Kamailio to crash:
(gdb) frame 2 #2 0x000000000049e39d in receive_msg ( buf=0x9065c0 "SIP/2.0 404 Not Found\r\nVia: SIP/2.0/UDP 55.177.31.199;branch=z9hG4bK022f.7350a5c7.0\r\nVia: SIP/2.0/UDP 68.68.120.41:5060;branch=z9hG4bK0cBc7d5138cbe6ccf3f\r\nRecord-Route: <sip:55.177.31.199;lr=on;ftag=gK0c0e4941;vsf=", 'A' <repeats 38 times>, "--;dlgcor=fae.b321>\r\nFrom: sip:16784841111@68.68.120.41;tag=gK0c0e4941\r\nTo: sip:12066513489@55.177.31.199;tag=6011e34882\r\nCall-ID: 1963749434_98793621@68.68.120.41\r\nCSeq: 4418 INVITE\r\nContact: sip:5282797646@195.105.225.111:5060;transport=udp\r\nSupported: 100rel, replaces, norefersub\r\nAllow-Events: refer\r\nAllow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE\r\nAccept: application/sdp\r\nUser-Agent: snomONE/4.5.1.1107 Zeta Perseids\r\nContent-Length: 0\r\n\r\n", len=717, rcv_info=0x7fff96469750) at receive.c:296 296 free_sip_msg(msg);
This time, it's not in dealing with the To bits, but freeing the SIP message in general:
(gdb) where #0 0x0000000000435908 in free_lump_list (l=0x7f4f81626730) at data_lump.c:510 #1 0x0000000000542d6a in free_sip_msg (msg=0x7f4f8180e970) at parser/msg_parser.c:731 #2 0x000000000049e39d in receive_msg ( buf=0x9065c0 "SIP/2.0 404 Not Found\r\nVia: SIP/2.0/UDP 55.177.31.199;branch=z9hG4bK022f.7350a5c7.0\r\nVia: SIP/2.0/UDP 68.68.120.41:5060;branch=z9hG4bK0cBc7d5138cbe6ccf3f\r\nRecord-Route: <sip:55.177.31.199;lr=on;ftag=gK0c0e4941;vsf=", 'A' <repeats 38 times>, "--;dlgcor=fae.b321>\r\nFrom: sip:16784841111@68.68.120.41;tag=gK0c0e4941\r\nTo: sip:12066513489@55.177.31.199;tag=6011e34882\r\nCall-ID: 1963749434_98793621@68.68.120.41\r\nCSeq: 4418 INVITE\r\nContact: sip:5282797646@195.105.225.111:5060;transport=udp\r\nSupported: 100rel, replaces, norefersub\r\nAllow-Events: refer\r\nAllow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE\r\nAccept: application/sdp\r\nUser-Agent: snomONE/4.5.1.1107 Zeta Perseids\r\nContent-Length: 0\r\n\r\n", len=717, rcv_info=0x7fff96469750) at receive.c:296 #3 0x000000000052ffa1 in udp_rcv_loop () at udp_server.c:557 #4 0x0000000000467de2 in main_loop () at main.c:1638 #5 0x000000000046ad8b in main (argc=13, argv=0x7fff96469a88) at main.c:2566
That leads me to believe that something in these replies from the PBX in general is causing memory corruption.