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.

- Nicholas.

-----Original Message-----
From: Julian Seward [mailto:jsew...@acm.org] 
Sent: Friday, September 16, 2016 4:35 AM
To: Nicholas Lamb <nl...@blackberry.com>; valgrind-users@lists.sourceforge.net
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
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