Wireshark-bugs: [Wireshark-bugs] [Bug 5821] Reduce per-packet memory requirements
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5821
Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff.morriss.ws@xxxxxxxxx
--- Comment #1 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2011-04-12 18:31:57 PDT ---
I had been toying with the idea of adding a memory-allocation tracing subsystem
in Wireshark. It would require instrumenting the code (adding traces of key
allocations and frees), but it could allow people to easily (maybe via the
Internals menu in the GUI?) where the memory [directly allocated by *shark] is
going in their particular capture file. A quick hack shows:
fragment storage: 0
struct dissector_handle: 157984
header_field_info: 8640000
heur_dtbl_entry_t: 2208
defragmented packet: 1496
PacketListRecord: 2590320
field_info: 5896
item_label_t: 3840
frame_data: 15541920
dtbl_entry_t: 99872
se_allocations: 19604064
proto_node: 3264
struct dissector_table: 6496
(the strings are free form; as such if you instrument an allocation and a
subsequent free, you have to be careful to use the same string.)
Would something like that be interesting to add? IOW, should I keep working on
it? (I would imagine it would be something you would turn on with an
environment variable.) The reason I thought of doing it is that I've never
been entirely sure where all the memory is going. (Now I see that if I had a
Mac I could find out, but I don't have a Mac... Does anyone know of a
Linux-based tool that does something similar?)
On a completely different note, should some of the Apple-specific libc
variables:
http://developer.apple.com/library/mac/releasenotes/DeveloperTools/RN-MallocOptions/_index.html
be added to the fuzz test script (for those of you who fuzz test on Macs)? A
couple of them look like they could be interesting.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
