Comment # 33
on bug 12656
from Guy Harris
So if I allocate the hash tables in question with wmem_epan_scope(), and don't
bother freeing them (leaving it up to the libwireshark code to free that
scope), I get
==35054== LEAK SUMMARY:
==35054== definitely lost: 12,818 bytes in 204 blocks
==35054== indirectly lost: 10,698 bytes in 316 blocks
==35054== possibly lost: 1,172,867 bytes in 9,249 blocks
==35054== still reachable: 269,464 bytes in 1,045 blocks
==35054== suppressed: 645,431 bytes in 357 blocks
Running tshark on an empty capture shows no CPU time differences between
"allocate with global scope" and "allocate with epan scope"; is there any
compelling reason *not* to use epan scope here?
You are receiving this mail because:
- You are watching all bug changes.
