Re: reclaiming memory before exit

[Bruno Haible]

Hi Paul,

> One issue is whether it's OK for test suites to leak memory (in the
> classic sense) because it's "just a test".  I'm of the opinion that
> tests should not contain those types of memory leaks and if someone
> comes along with a fix, it should be applied.  I don't think it's
> necessary for developers to proactively go looking for these though.

Yes, that's the habit we have adopted in gnulib after some debate. [1]

> The next set of issues are the ones discussed in the 2018 thread:
> singleton objects such as memory kept by bindtextdomain(), init files,
> caches, etc.
> 
> I don't understand why these are a problem: this memory is not lost. 
> Those libraries continue to refer to that memory (perhaps through some
> global variable) and as such, memory checkers like valgrind won't
> complain about them (at least, that's been my experience).

Well, my experience is different. Last month, I analyzed a program
that uses GNU libtextstyle, and the valgrind "leak" reports could be
categorized into three groups:
  * 1056 + 296 + 56 bytes, allocated through cr_style_init_properties
    (inside libcroco). This is a statically allocated hash table with
    a fixed number of entries. It can be ignored.
  * Allocations inside libcurses. Discussed in this thread: [2].
  * A real leak, which I fixed. [3]

> Or, are the leak detectors not as
> sophisticated as I think about referenced/unreferenced memory and I've
> just been lucky with them so far?

I think it's this, yes.

> Maybe we are just talking about the specific text in the GNU guide,
> i.e. this paragraph:
> 
> > Memory analysis tools such as valgrind can be useful, but don’t
> > complicate a program merely to avoid their false alarms. For example,
> > if memory is used until just before a process exits, don’t free it
> > simply to silence such a tool.
> 
> Are people are reading more into it than it says, and interpreting this
> as "GNU programs should not free memory before exit"?  That's not how I
> read it.  "Don't complicate programs _only_ to silence memory analysis
> tools" leaves plenty of other reasons to free before exit, including
> being a shared library, or even just because it's the policy of the
> project to do so.  Those seem perfectly fine reasons to me.
> 
> However, maybe this language could be made more nuanced.

The discussion is not only about language nuances. There are people
who request that GNU programs should free all memory before exit(),
_only_ to silence memory analysis tools.

Like it was with "gcc -Wall" warnings. 20 years ago, people like me
were saying "let me use 'gcc -Wall' since it produces useful warnings;
some warnings can remain since I know them". But other people insisted
that no warnings should remain, because they want to see new warnings
clearly and immediately, without having to learn beforehand which
warnings they need to expect.

It's similar with the valgrind output. The tool is more useful if,
in the normal situation, it produces no stack traces, than if it normally
shows 25 stack traces, from libncurses, libcroco, and libtextstyle,
all intermixed.

That's what the discussion is about.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2019-03/msg00025.html
[2] https://lists.gnu.org/archive/html/bug-ncurses/2009-04/msg00028.html
[3] 
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=1d166f60e79d39d2ba1342e68f96104c24c85fb7