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 m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users