Re: reclaiming memory before exit, take 2

2020-05-16 Thread Paul Smith
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

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Bruno Haible
Jeffrey Walton wrote: > I prefer to run a release > build with diagnostics. Something like '-g2 -O3 -DNDEBUG > -fsanitize=asan', install it, and then use it long term. > > One of the [many] reasons this is important is, it provides additional > coverage beyond the test cases. In the wild I may

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Paul Eggert
On 5/16/20 10:26 AM, Bruno Haible wrote: > Are you suggesting that QA automation should ignore the global and static > variables? No, merely that attention should be focused on important leaks, not unimportant ones. Memory that is needed during program execution, and that becomes not-needed just

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Bruno Haible
Hi Paul, > > 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. > > This division of labor is not universal. In many shops, QA engineers are more > involved

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Jeffrey Walton
On Sat, May 16, 2020 at 12:47 PM Bruno Haible wrote: > > Tim Rühsen wrote: > > 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

Re: reclaiming memory before exit, take 2

2020-05-16 Thread 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

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Bruno Haible
Tim Rühsen wrote: > 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. How about using an environment

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Tim Rühsen
Hi, thanks for your excellent write-up, Bruno. Just want to add my thoughts :) 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, ...).

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Tim Rühsen
On 16.05.20 17:33, Jeffrey Walton wrote: > On Sat, May 16, 2020 at 10:05 AM Bruno Haible 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

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Paul Eggert
Thanks for the summary. On 5/16/20 7:04 AM, 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

Re: reclaiming memory before exit, take 2

2020-05-16 Thread Jeffrey Walton
On Sat, May 16, 2020 at 10:05 AM Bruno Haible wrote: > > Hi all, > > Let me try to bring some structure into this discussion. > > 1) The memory-leak tools > 2) The developer's perspective > 3) The QA automation perspective > > > 1) The memory-leak tools > > > Paul and I

reclaiming memory before exit, take 2

2020-05-16 Thread Bruno Haible
Hi all, Let me try to bring some structure into this discussion. 1) The memory-leak tools 2) The developer's perspective 3) The QA automation perspective 1) The memory-leak tools Paul and I apparently use the tools differently [1]. So, I've written a wiki page