Re: reclaiming memory before exit, take 2

[Tim Rühsen]

On 16.05.20 17:33, Jeffrey Walton wrote:
> On Sat, May 16, 2020 at 10:05 AM Bruno Haible <address@hidden> wrote:
>> 3) The QA automation perspective
>> ================================
>>
>> For QA automation, a multitude of program executions are done with a
>> memory leak checker enabled. Since it needs to be automated, the usual
>> policy will be that a valgrind or leak sanitizer report is considered
>> a failure.
>>
>> The QA automation needs to rely on the suppression files created by the
>> developers, since it's not a QA engineer's job to evaluate whether a
>> particular memory leak is serious or not.
>>
>> A good QA automation will thus use 'valgrind --show-reachable=yes'
>> and the developer's suppression files.
>>
>>
> 
> GNU values choice for the user.
> 
> Perhaps GNU should provide a configuration option
> --enable-memory-leaks for those who want them. The rest of the world
> can enjoy a clean module that can pass through code quality and
> security gates.

Free'ing memory can cost *a lot* of CPU. In the best case this is
completely superfluous, in most cases this leads to a slowdown of
software, to increased energy consumption, to higher costs, and produces
more CO2 than needed.

So by default, applications should not free memory before exit.

But I agree that people who want to test for memory leaks (and most
developers want this for their own projects) should have an easy way to
do this.

At GNU wget we have conditional cleanup functions. That is compilation
with -DDEBUG_MALLOC in $CFLAGS will add those cleanup functions and they
are called before wget exits. Handy for testing, but you have to build
an extra executable.

If the GNU project could agree on a standard regarding such a flag or
even a command line option - I wouldn't be against it.

Regards, Tim

signature.asc
Description: OpenPGP digital signature