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.