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
it --
> 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 specific
> to find references that haven't been used in a while?

Valgrind-users mailing list

Reply via email to