bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reclaiming memory before exit


From: Paul Smith
Subject: Re: reclaiming memory before exit
Date: Fri, 15 May 2020 18:38:29 -0400

On Fri, 2020-05-15 at 21:58 +0200, Bruno Haible wrote:
> Another possibility is to standardize on a GCC attribute for
> functions, with the meaning "memory allocations done inside this
> functions are on the same level as static initializations and don't
> need to be reclaimed before program exit".

I think it would be as specific as possible.

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.

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).

So what exactly are we talking about here?

There might be memory that is referenced by a local variable in main(),
which would be considered lost if main() returns without freeing it. 
It seems easy enough to turn that into a static variable, for example,
to avoid that check without any downsides or complications in the code.

Alternatively main() could invoke exit() or _exit() and since it never
returns, its memory is still referenced (I don't know whether this will
satisfy memory leak detectors or not).

Are we talking about something else?  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?

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]