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