5 Sep
2013
5 Sep
'13
10:27 a.m.
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(a)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(a)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.
--
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/