Is ALLOCATION with allocator=free actually a DEALLOCATION?

[gh-andre]

I'm trying to find the number of deallocations within some function and I cannot find any references to how deallocations are reported. They are mentioned in docs for --leaks, but in various output types, such as flamegraph, I only see allocations. This leads me to 2 questions:

1. In the parse command output, like the one below, does it mean that there were 2 allocations and 1 deallocation, even though all rows have ALLOCATION in them? In other words, should ALLOCATION be interpreted as "one of memory allocation functions was used" and not that "a memory allocation function was invoked"?

FRAME_PUSH frame_id=5646 ALLOCATION address=0x5a928b40a780 size=40 allocator=malloc ALLOCATION address=0x5a928b3ef2f0 size=64 allocator=malloc ALLOCATION address=0x5a928a922ab0 size=0 allocator=free FRAME_POP count=2 

2. When I see in a flamegraph output 17.3 KiB, 50 allocations, it seems that these are actual memory allocations, as far as I can see from the parse output when matching frame blocks. Is it correct that when this report is generated with --leaks, then only unmatched allocations are shown, and otherwise all allocations are shown?

As a side note, it would be really useful if each flame graph hover panel would show allocations and deallocations, along with their sizes, which would allow one to see the leaks in a single flamegraph output.

Thanks!

[godlygeek]

1. In the parse command output, like the one below, does it mean that there were 2 allocations and 1 deallocation, even though all rows have ALLOCATION in them?

Yes, this is recording that malloc was called twice to allocate some memory, first returning the pointer 0x5a928b40a780 and then returning the pointer 0x5a928b3ef2f0, and later free was passed the pointer 0x5a928a922ab0 to deallocate some memory. So two allocations were performed, and then a 3rd (different) allocation was freed.

2. When I see in a flamegraph output 17.3 KiB, 50 allocations, it seems that these are actual memory allocations, as far as I can see from the parse output when matching frame blocks. Is it correct that when this report is generated with --leaks, then only unmatched allocations are shown, and otherwise all allocations are shown?

The --leaks mode of memray flamegraph shows all of the allocations that were made after tracking started and that were not freed before tracking ended. The non --leaks mode shows all of the allocations that were made after tracking started and that were not freed before the program reached its largest amount of memory used.

As a side note, it would be really useful if each flame graph hover panel would show allocations and deallocations, along with their sizes, which would allow one to see the leaks in a single flamegraph output.

Fundamentally, the --leaks mode and the non --leaks mode are showing allocations as of a different moment in time. Both are showing allocations made after the start of tracking and not freed by some particular instant, but they're reporting about a different instant. The --leaks mode is showing allocations made after the start of tracking and not freed by the end of tracking, while the non --leaks mode is showing allocations made after the start of tracking and not freed by the moment when the highest amount of heap memory was used. There's no reasonable way to show those both on the same graph, because fundamentally they're reporting on what was happening at two different points in time.

[gh-andre]

Thanks for responding and answering the questions. Much appreciated.

WRT --leaks and no---leaks, it's always about allocation pointers along with their stacks and pointers used to free blocks with their stacks. Any leak detector would locate allocations without dealocations for a given object and an app or a component run. That's pretty much how most C/C++ memory profilers work, like AQTime. I would typically just look at the mismatching allocation/deallocation counts/sizes, whether it's for the entire app or a component run, and would compare all those against what was supposed to be freed.

Anyway, just wanted to clarify. Thanks again for your insights and a fantastic app.