Honestly the best tool for any of this kind of job is Valgrind's Massif profiler [1].
It's already supported by our valgrind script - just run ./tools/valgrind-wireshark -m capture.pcap which will produce an output file massif.out.PID. The 'ms_print' command dumps human-readable summaries from that. Of course valgrind doesn't exist on Windows, but if the problem is reproducible with a capture file then it's pretty easy to rerun in a linux vm. The difficulty with our own instrumentation framework is that it would be very difficult to tell where the memory allocation requests are coming from - there's no cross-platform way that I know of to get a stack backtrace with human-readable function names... [1] http://valgrind.org/docs/manual/ms-manual.html On Thu, Jul 25, 2013 at 10:16 AM, Anders Broman <[email protected]> wrote: > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jeff Morriss > Sent: den 25 juli 2013 15:28 > To: Developer support list for Wireshark > Subject: Re: [Wireshark-dev] Chart of wireshark memory usage > > On 07/25/13 08:18, Evan Huus wrote: >> On 2013-07-25, at 12:47 AM, Anders Broman <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Jakub Zawadzki skrev 2013-07-20 16:41: >>>> Hi all, >>>> >>>> Recently I was trying to move io_stat graph functionality to some >>>> GtkWidget. >>>> For now I failed, but as a side effect result I've created memory >>>> usage dialog ;] >>>> >>>> It looks like >>>> this:http://www.wireshark.org/~darkjames/memory_dlg.png >>>> >>>> Attaching dirty patch (not ready for merging), enjoy. >>>> >>>> Cheers, >>>> Jakub. >>>> >>> Hi, >>> I committed the memory_dlg code as I made it work on windows and it >>> will be easier to collaborate on it in SVN. For the emem patch should >>> it return both the allocated and used sizes as that would be a more >>> accurate indication of the memory used by the application. >>> >>> For the function reading the memory used by the application should >>> that be in it's on section in epan or wsutil if it's useful for other >>> purposes? Part of the summary information? >>> Regards >>> Anders >> >> If people are interested in pursuing this further, it would be very >> easy to write a wmem allocator that provides much more detailed >> statistics (number of allocations by size, for example). Not >> everything goes though wmem yet, but I'll get there eventually. > > I looked at adding some kind of profiling to Wireshark's memory usage some > years ago (but lost interest in my method). What I *really* wanted to know > was "where is the memory going?" Is it TCP reassembly, frame_data's, or > what? And I wanted it to be visible in a normal Wireshark build so if some > user complained of high memory usage we could see what, in their particular > trace file, was causing the usage. > > I was thinking that when we have the framework in place we can add queries to > read hash table sizes etc, it might not give the exact > Memory usage but at least an approximation(Hmm might not work for fragment > tables...as the fragment size isn't known). > Regards > Anders > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
