Re: reclaiming memory before exit, take 2

[Bruno Haible]

Hi Tim,

> When talking about finding memory leaks, like in your wiki page, you
> should also mention static analyzers and their ability to find memory
> leaks (clang static analyzer, gcc-10 -fanalyzer, Coverity, cppcheck, ...).

Would you like to add one or more wiki pages about these static analyzers?

> These are able to find leaks (and much more) even in code that is seldom
> used during runtime (and perhaps never during testing).
> To find all those leaks with runtime tools like valgrind, you need  a
> very high code coverage in your test suite.

You are right. Your argument applies to memory leaks as well as file
descriptor leaks.

Personally I've used a static analyzer with the purpose of finding file
descriptor leaks but not for memory leaks. I don't know why; maybe
because for file descriptor leaks there are fewer reports and thus
fewer false findings to eliminate? Or because we have valgrind for the
memory leaks but no experience with 'valgrind --track-fds'?

> Another point is: a library exit / cleanup call before exiting the
> application can easily free all reachable memory and by that disguise or
> hide internal memory leaks that lead to OOM in a long-running
> application (daemon or e.g. wget -r).
> In these cases it may be helpful to *not* free memory and not call exit
> library functions before exiting the application. Only then could
> valgrind show the memory hog (maybe the --xtree-memory option is for
> exactly that - I didn't investigate it yet).

It sounds like what you would need here is "heap profiling"
('valgrind --massif').

Bruno