Don't forget that what I actually asked are the log messages with memory
operations. It was an indication of buffer overflow.
Cheers,
Daniel
On 9/5/13 12:36 PM, Alex Balashov wrote:
On 09/05/2013 06:27 AM, Alex Balashov wrote:
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
This is the crash I get ~80-90% of the time, though. This leads me to
believe that the To params probably have more to do with it than
anything else, unless the structure of the memory corruption is such
that it just happens to explode there.
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at
http://www.asipto.com -