Comment # 4
on bug 8343
from Evan Huus
(In reply to comment #3)
> (In reply to comment #1)
> > Looks like another one for you Michael - more weirdness with the SDP hash
> > table. I'll attach some valgrind output, and I've pasted the relevant part
> > of one of the backtraces below:
>
>
> Any hints as to the packet number? Am I reading this right in that its just
> a memory leak I'm chasing?
It's a crasher - the valgrind output lists a whole bunch of used-after-freed
memory. The crash is coming at packet 208, but I think the issue involves a
couple of the packets before as well.
A sample trace from the valgrind log:
Invalid read of size 8
at 0x922E19D: g_hash_table_insert_internal (ghash.c:365)
by 0x691937F: call_sdp_subdissector (packet-sdp.c:1263)
by 0x691A171: setup_sdp_transport (packet-sdp.c:1807)
by 0x69317E7: dissect_sip_common (packet-sip.c:3151)
by 0x693212F: dissect_sip (packet-sip.c:2003)
by 0x636F45E: call_dissector_through_handle (packet.c:454)
by 0x636FCBC: call_dissector_work (packet.c:549)
by 0x63704FF: dissector_try_uint_new (packet.c:969)
by 0x6370556: dissector_try_uint (packet.c:995)
by 0x69ECB4F: decode_udp_ports (packet-udp.c:271)
by 0x69ED16F: dissect (packet-udp.c:593)
by 0x636F417: call_dissector_through_handle (packet.c:458)
Address 0x134a58b0 is 48 bytes inside a block of size 88 free'd
at 0x4C2BA6C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x691A56A: setup_sdp_transport (packet-sdp.c:1923)
by 0x69317E7: dissect_sip_common (packet-sip.c:3151)
by 0x693212F: dissect_sip (packet-sip.c:2003)
by 0x636F45E: call_dissector_through_handle (packet.c:454)
by 0x636FCBC: call_dissector_work (packet.c:549)
by 0x63704FF: dissector_try_uint_new (packet.c:969)
by 0x6370556: dissector_try_uint (packet.c:995)
by 0x69ECB4F: decode_udp_ports (packet-udp.c:271)
by 0x69ED16F: dissect (packet-udp.c:593)
by 0x636F417: call_dissector_through_handle (packet.c:458)
by 0x636FCBC: call_dissector_work (packet.c:549)
You are receiving this mail because:
- You are watching all bug changes.
