Re: Chart of wireshark memory usage

[Evan Huus <eapache () gmail com>]

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
<anders.broman () ericsson com> wrote:
> -----Original Message-----
> From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] 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 <a.broman () bredband net
> > <mailto:a.broman () bredband net>> 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 <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe