Comment # 31
on bug 12656
from Guy Harris
(In reply to Guy Harris from comment #30)
> For what it's worth, addr_resolv_cleanup(), called from epan_cleanup(),
> called before TShark - and other programs - exit, calls
> eth_name_lookup_cleanup(), which does
>
> wmem_free(NULL, manuf_hashtable);
> manuf_hashtable = NULL;
>
> but doesn't free anything in the hash table in question, so that might
> render the manufacturer-OID-to-name table entries "definitely unreachable".
>
> Should we allocate those entries in epan scope, so they're freed-in-bulk by
> epan_cleanup()?
If I #if 0 out all of eth_name_lookup_cleanup(), and run tshark under valgrind
with that capture, it reports
==28661==
==28661== HEAP SUMMARY:
==28661== in use at exit: 3,159,806 bytes in 41,121 blocks
==28661== total heap usage: 122,091 allocs, 80,970 frees, 47,139,021 bytes
al$
==28661==
==28661== LEAK SUMMARY:
==28661== definitely lost: 12,962 bytes in 207 blocks
==28661== indirectly lost: 1,059,082 bytes in 30,263 blocks
==28661== possibly lost: 1,172,867 bytes in 9,249 blocks
==28661== still reachable: 269,464 bytes in 1,045 blocks
==28661== suppressed: 645,431 bytes in 357 blocks
==28661== Rerun with --leak-check=full to see details of leaked memory
==28661==
==28661== For counts of detected and suppressed errors, rerun with: -v
==28661== Use --track-origins=yes to see where uninitialised values come from
==28661== ERROR SUMMARY: 20 errors from 4 contexts (suppressed: 0 from 0)
which is a lot less "definitely lost" - an a lot more "indirectly lost" and
"possibly lost" (admittedly, with a later version to TShark).
You are receiving this mail because:
- You are watching all bug changes.