Re: reclaiming memory before exit, take 2

[Paul Smith]

On Sat, 2020-05-16 at 16:04 +0200, Bruno Haible wrote:
> Paul writes in [1]:
> > In any event, it seems to me to be a deficiency in the detection if
> > it reports allocated memory which is still referenced to by global
> > variables, or even static variables, as memory leaks.
> 
> On the contrary, reporting leaks through global and static variables
> is a feature. *Hiding* them, which is what the tools do by default,
> is a *misfeature*.
> 
> Why? Because caches that grow without bounds are serious memory leaks
> as well. It is pointless to eliminate serious memory leaks that were
> caused by forgetting free(), while at the same not noticing serious
> memory leaks that were caused by bad design of caches. BOTH have same
> adverse effects.
> 
> This means, when looking for memory leaks, you should use valgrind
> with '--show-reachable=yes'.

I'm afraid I don't agree with this position, although of course I only
speak for the GNU make project.

To me memory leaks have a very specific meaning: memory that was
allocated but is no longer referenced and hence not recoverable.  This
is the only type of problem that leak detectors are good for
discovering.

A cache that grows very large may or may not be an error: no tool can
automatically determine whether it is appropriate or not.

It may mean that your program needs to do a lot of work and is choosing
an entirely reasonable trade-off of memory for another resource (say
disk IO).

Or, certainly, it may be a signal that the algorithms you've chosen to
solve the problem are not up to the task, or even that you have a bug
in them (not reusing cache when you can or should).  To decide that
you'll need to use a memory profiler and discover how much memory is
being used and where, and see if there's an issue.

IMO "--show-reachable=yes" is an anti-pattern and should not be used:
it provides nothing but false positives and the only way to avoid them
is to implement "final free", which won't help you discover too-large
caches anyway, or add suppression files for known-correct allocations,
which you should certainly prefer to avoid.