Comment # 32
on bug 12656
from Guy Harris
The more detailed output for the version with the freeing #ifdeffed out is
==28739== 242,344 (48 direct, 242,296 indirect) bytes in 1 blocks are
definitely lost in loss record 2,861 of 2,865
==28739== at 0x100054D81: malloc (vg_replace_malloc.c:303)
==28739== by 0x1001B3CB8: g_malloc (in /usr/local/lib/libglib-2.0.0.dylib)
==28739== by 0x105575C7D: wmem_map_new (wmem_map.c:90)
==28739== by 0x1048535E2: addr_resolv_init (addr_resolv.c:1289)
==28739== by 0x1048653B3: epan_init (epan.c:110)
==28739== by 0x10000C063: main (tshark.c:804)
==28739==
==28739== 800,152 (48 direct, 800,104 indirect) bytes in 1 blocks are
definitely lost in loss record 2,865 of 2,865
==28739== at 0x100054D81: malloc (vg_replace_malloc.c:303)
==28739== by 0x1001B3CB8: g_malloc (in /usr/local/lib/libglib-2.0.0.dylib)
==28739== by 0x105575C7D: wmem_map_new (wmem_map.c:90)
==28739== by 0x1048535FE: addr_resolv_init (addr_resolv.c:1290)
==28739== by 0x1048653B3: epan_init (epan.c:110)
==28739== by 0x10000C063: main (tshark.c:804)
and those are allocating the well-known address and manufacturer hash tables,
respectively.
I'm not sure how they're "definitely lost", as the hash table pointers didn't
get nulled out at the end, but I think that's a big source of Stuff That Gets
Freed By The OS Tearing Down The Process Address Space So Valgrind Complains
About It.
You are receiving this mail because:
- You are watching all bug changes.