I think Memcheck actually can say something about accessible but unreleased
blocks, but by default it doesn't. The show-leak-kinds option, according to the
Valgrind manual, can contain the 'reachable' value. In this case, Memcheck
reports blocks that could have been freed but weren't.
But I guess it depends on what you mean by "only freed at the end". If you mean
there's an explicit call to free() or delete, then Memcheck obviously wouldn't
report these blocks. If you mean the programmer makes no such call, knowing
that the OS cleans up the memory when the program exits, these blocks would
qualify as 'reachable' leaks.
I suppose the advantage of Massif is that it reveals the breakdown of heap
memory distribution, so you can know how much memory is taken by accessible but
unreleased blocks. I'm using a variant of the Eclipse IDE that provides good
visualization of Massif's output, so I guess it's just a matter of examining
the detailed snapshots to find memory blocks that account for a large portion
of overall used memory but haven't been used for a while.
From: Julian Seward [mailto:jsew...@acm.org]
Sent: Friday, September 16, 2016 4:35 AM
To: Nicholas Lamb <nl...@blackberry.com>; email@example.com
Subject: Re: [Valgrind-users] Using Massif to find space leaks
This is all a bit cryptic, but what it means is: Memcheck will tell you about
leaks where all pointers to a block are lost, so it can never be freed. But it
doesn't say anything about a different kind of leak, in which blocks are
continuously allocated over the lifetime of the program, but only ever freed at
the end. So memory use ramps up forever despite the fact that in the end, all
memory is freed.
Massif can tell you about these leaks, because they show up as ever- increasing
residency from some specific allocation point.
Try using Milian Wolff's excellent massif-visualizer GUI. That makes it very
easy to examine the output of Massif in detail and find such leaks.
At least on Fedora 23 you can ask the package manager to install it.
I'm guessing here, but I suspect you can take the Massif output from a run such
as on a phone, move it to a host machine, and view with massif-visualizer there.
On 15/09/16 21:40, Nicholas Lamb wrote:
> In the Valgrind User Manual, the Massif chapter mentions:
> "certain space leaks ... aren't detected by traditional leak-checkers, such
> as Memcheck's.
> That's because the memory isn't ever actually lost -- a pointer
> remains to
> but it's not in use. ... Massif can help identify these leaks."
> The sample program and output graph sections explain how to visually
> interpret the output after it's run through ms_print, as well as the
> concepts of detailed and heap snapshots, but there isn't any example
> given of finding space leaks.
> What are the high-level steps for doing so? Would users examine the
> detailed snapshots and analyze the breakdown of memory consumption in
> to find references that haven't been used in a while?
Valgrind-users mailing list