Re: massif & counts per type

Milian Wolff <[email protected]> Fri, 11 Sep 2020 16:53:01 +0200
Newsgroups	gmane.comp.debugging.valgrind
Message-ID	<2708399.KlBsvKRTlt@milian-workstation>
On Freitag, 11. September 2020 12:50:18 CEST folkert wrote:
> Hi,
> 
> > > How can I obtain the number of mallocs per type in a time-frame using
> > > massif? I'm NOT interested in the total in use, I would like to know how
> > > often type x is allocated between t+1 and t+2.
> > 
> > To my knowledge, this data is not recorded by Massif. You could try to
> > have a look at heaptrack [1] instead.
> > 
> > [1]: https://invent.kde.org/sdk/heaptrack
> > 
> > Note though that on Linux, malloc does not retain any type information. As
> > such, even with heaptrack you cannot easily filter by type. But by
> > leveraging the flamegraph you can often still get a similar intuition
> > based on the callstacks. I have an idea to parse the callstack code lines
> > to find type information from the call to `new` but that's probably quite
> > hairy to get right in practice. Suggestions welcome on how to trace the
> > type information!
> > 
> > And finally, with heaptrack it is also not yet easily doable to get a diff
> > between two time stamps. Also a feature I've long thought about
> > implementing, but never got around to...
> 
> This morning I came up with an other solution: I made a LD_PRELOAD
> wrapper which counts every malloc-call. Decided that allocated-type is
> not really required in my case, but to know which malloc did it would
> work as well.
> So in malloc() I do __builtin_return_address(0), hash the pointer and
> use that as an index in array of counters.
> 
> Gives me:
> 
> pointer          count
> ...
> 000000000041db10 00000000002a427
> 00007ffff4a6c1b1 00000000007f1da
> 
> Going from 000000000041db10 to a symbol works fine, the shared library
> (00007ffff4a6c1b1) is a bit troublesome though (disabled
> randomize_va_space and using eu-addr2line).

You have to take the memory mapping of the library into account and subtract 
that offset from the address.

Anyhow, it sounds like you are starting to reinvent heaptrack - it does 
exactly the above and then some.

Cheers

-- 
Milian Wolff
[email protected]
http://milianw.de

_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
signature.asc (application/pgp-signature, 833 B)