[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 13 on bug 9920 from Evan Huus

I don't know enough about SIP/SDP/RDP and the relevant state that needs saving
but it sounds to me like even a wmem hash table would only sort of fix the leak
(in that all the memory would eventually be freed, but much of it would be
"dead" long before that). This isn't a problem with packet-scoped memory since
it's lifetime is so short, but its something I've been trying to avoid with
file-scoped memory.

> So the wmem-managed struct has a pointer to the hashtable, but I assume wmem
> doesn't somehow magically go call g_hash_table_destroy() on the member
> hashtable right? :)

Not unless you register a callback, which is probably the easiest thing to do.
The alternatives are write a wmem hash table (which is on my far-future todo
list) or switch everything to wmem trees (which would probably be a performance
hit).

---

And yes, valgrind confirms that the capture file (the fuzzbot, not the minimal)
does leak some memory. Relevant snips:

==26021== 2,464 (1,056 direct, 1,408 indirect) bytes in 12 blocks are
definitely lost in loss record 3,613 of 3,688
==26021==    at 0x4C2A420: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26021==    by 0x977F610: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==26021==    by 0x979522D: g_slice_alloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==26021==    by 0x976917D: g_hash_table_new_full (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==26021==    by 0x6B54F1B: dissect_sdp (packet-sdp.c:2285)
==26021==    by 0x655EF03: call_dissector_through_handle (packet.c:595)
==26021==    by 0x655F7F4: call_dissector_work (packet.c:682)
==26021==    by 0x6560182: dissector_try_string (packet.c:1385)
==26021==    by 0x6B6CCF5: dissect_sip_common (packet-sip.c:3563)
==26021==    by 0x6B6E680: dissect_sip (packet-sip.c:2253)
==26021==    by 0x655EF3E: call_dissector_through_handle (packet.c:591)
==26021==    by 0x655F7F4: call_dissector_work (packet.c:682)

==26021== 248 (88 direct, 160 indirect) bytes in 1 blocks are definitely lost
in loss record 3,344 of 3,688
==26021==    at 0x4C2A420: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26021==    by 0x977F610: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==26021==    by 0x979522D: g_slice_alloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==26021==    by 0x976917D: g_hash_table_new_full (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==26021==    by 0x6B5595E: setup_sdp_transport (packet-sdp.c:1921)
==26021==    by 0x6B6DE68: dissect_sip_common (packet-sip.c:3545)
==26021==    by 0x6B6E680: dissect_sip (packet-sip.c:2253)
==26021==    by 0x655EF3E: call_dissector_through_handle (packet.c:591)
==26021==    by 0x655F7F4: call_dissector_work (packet.c:682)
==26021==    by 0x655FEAB: dissector_try_uint_new (packet.c:1113)
==26021==    by 0x655FF06: dissector_try_uint (packet.c:1139)
==26021==    by 0x6C2C257: decode_udp_ports (packet-udp.c:411)
==26021==

---

      You are receiving this mail because:

• You are watching all bug changes.