|
From: folkert <fo...@va...> - 2020-09-10 13:26:51
|
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. regards |
|
From: folkert <fo...@va...> - 2020-09-11 10:51:04
|
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). Folkert van Heusden -- |
|
From: John R. <jr...@bi...> - 2020-09-11 15:11:11
|
On 2020-09-11 at 10:50 UTC, folkert wrote:
[snip]]
> 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.
For a random C++ program, then most calls to malloc are made by 'operator new'
or some closely-related flavor. After that comes std::string::alloc<...>.
You *really* want 'heaptrack'. Get it (and libunwind)! Use it!
Do not waste your time trying to concoct anything else.
|
|
From: Milian W. <ma...@mi...> - 2020-09-11 10:58:56
Attachments:
signature.asc
|
On Donnerstag, 10. September 2020 15:26:37 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... Cheers -- Milian Wolff ma...@mi... http://milianw.de |
|
From: Philippe W. <phi...@sk...> - 2020-09-12 14:24:17
|
On Fri, 2020-09-11 at 12:38 +0200, Milian Wolff wrote: > 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... Note that valgrind allows to report a "delta/diff" memory heap status e.g. under memcheck. See memcheck leak_check monitor command. Philippe |
|
From: Milian W. <ma...@mi...> - 2020-09-11 14:54:31
Attachments:
signature.asc
|
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 ma...@mi... http://milianw.de |
|
From: folkert <fo...@va...> - 2020-09-12 13:00:52
|
> Anyhow, it sounds like you are starting to reinvent heaptrack - it does > exactly the above and then some. Indeed it does: I looked at and it is perfectly for my use-case. Thank you! |
|
From: Philippe W. <phi...@sk...> - 2020-09-12 14:22:23
|
On Thu, 2020-09-10 at 15:26 +0200, 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. You could run your application under valgrind + gdb/vgdb. You can then put breakpoints at relevant places to trigger them at t+1 and t+2. You can then e.g. run with memcheck and have delta malloc info being reported, using the memcheck monitor command leak_check. This command can show the delta "alloc/free" since the previous call. Philippe |