[sr-dev] Crash bug freeing To headers

[Alex Balashov]

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 at 68.68.120.41>;tag=gK0c0e4941\r\nTo:
> <sip:12066513489 at 55.177.31.199>;tag=6011e34882\r\nCall-ID:
> 1963749434_98793621 at 68.68.120.41\r\nCSeq: 4418 INVITE\r\nContact:
> <sip:5282797646 at 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 at 68.68.120.41>;tag=gK0c0e4941\r\nTo:
> <sip:12066513489 at 55.177.31.199>;tag=6011e34882\r\nCall-ID:
> 1963749434_98793621 at 68.68.120.41\r\nCSeq: 4418 INVITE\r\nContact:
> <sip:5282797646 at 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.
>
>


-- 
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/