Re: reclaiming memory before exit, take 2

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 contrary,

Re: reclaiming memory before exit, take 2

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 enc

Re: reclaiming memory before exit, take 2

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

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

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 bu

Re: reclaiming memory before exit, take 2

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 analy

Re: reclaiming memory before exit, take 2

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 varia

Re: reclaiming memory before exit, take 2

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

Re: reclaiming memory before exit, take 2

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 au

Re: reclaiming memory before exit, take 2

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 c

Re: reclaiming memory before exit, take 2

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 ap

reclaiming memory before exit, take 2

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 https:

Re: reclaiming memory before exit

On Sat, 2020-05-16 at 01:03 +0200, Bruno Haible wrote: > 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

Re: reclaiming memory before exit

Jeffrey Walton wrote: > Allow me to rephrase again as if I am speaking to executives: GNU > should embrace a diversity of leadership. This topic is off-topic on this list. Please don't discuss it here. First, read [1]. Then, you can discuss it privately with Richard Stallman and the members of the

Re: reclaiming memory before exit

On Fri, May 15, 2020 at 6:07 PM Paul Smith wrote: > > On Fri, 2020-05-15 at 16:38 -0400, Jeffrey Walton wrote: > > On Fri, May 15, 2020 at 4:23 PM Paul Eggert > > > To fix this problem you need to fix GNU itself. They need new blood > > in leadership that understands and embraces modern engineeri

Re: reclaiming memory before exit

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

Re: reclaiming memory before exit

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

Re: reclaiming memory before exit

On Fri, 2020-05-15 at 16:38 -0400, Jeffrey Walton wrote: > On Fri, May 15, 2020 at 4:23 PM Paul Eggert > wrote: > > On 5/15/20 10:52 AM, Kamil Dudka wrote: > > > I do not understand why you take it personally. > > > > I didn't take it personally. The email in question wasn't even > > directed at

Re: reclaiming memory before exit

On Fri, May 15, 2020 at 4:23 PM Paul Eggert wrote: > > On 5/15/20 10:52 AM, Kamil Dudka wrote: > ... > > I do not understand why you take it personally. > > I didn't take it personally. The email in question wasn't even directed at > me. I > do value civility, though. There was nothing uncivil o

Re: reclaiming memory before exit

On 5/15/20 10:52 AM, Kamil Dudka wrote: > There are certainly many > modern software projects that have higher requirements on cleanup of resources Sure, just as there used to be software projects that had "higher" requirements on using the Hungarian notation. Although those requirements may have

Re: reclaiming memory before exit

On Fri, May 15, 2020 at 3:58 PM Bruno Haible wrote: > > Kamil Dudka wrote: > > How old is the text in GNU standards that Bruno refers to? > > How old it is, is irrelevant because the two main points are valid and will > continue to be valid (if the tools don't change): > > 1) The sentence "if me

Re: reclaiming memory before exit

Kamil Dudka wrote: > How old is the text in GNU standards that Bruno refers to? How old it is, is irrelevant because the two main points are valid and will continue to be valid (if the tools don't change): 1) The sentence "if memory is used until just before a process exits, don’t free it

Re: reclaiming memory before exit

On Friday, May 15, 2020 5:16:28 AM CEST Paul Eggert wrote: > On 5/14/20 5:11 PM, Jeffrey Walton wrote: > > Not everyone has GNU's low standards. > > Now may be a good time to remind us of the GNU Kind Communications > Guideline; see . > Let's

Re: reclaiming memory before exit

Jeffrey, > > We discussed this already in the thread starting at [1]. > > Not everyone has GNU's low standards. You are one of the few persons who apply analysis and checking tools to many GNU projects, more than anyone else [2][3]. This is appreciated (as long as the reports are about platforms

Re: reclaiming memory before exit

On Thu, May 14, 2020 at 11:16 PM Paul Eggert wrote: > > On 5/14/20 5:11 PM, Jeffrey Walton wrote: > > Not everyone has GNU's low standards. > > Now may be a good time to remind us of the GNU Kind Communications Guideline; > see . Let's not le

Re: reclaiming memory before exit

On 5/14/20 5:11 PM, Jeffrey Walton wrote: > Not everyone has GNU's low standards. Now may be a good time to remind us of the GNU Kind Communications Guideline; see . Let's not let honest technical disagreements degenerate into name-calling.

Re: reclaiming memory before exit

On Thu, May 14, 2020 at 8:00 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > > Building RPMs with -Dlint would mean performance > > > penalty because some programs (e.g. sort) would explicitly release complex > > > data structures just before exit, which is wasteful. > > > > I think it may be

Re: reclaiming memory before exit

Jeffrey Walton wrote: > > Building RPMs with -Dlint would mean performance > > penalty because some programs (e.g. sort) would explicitly release complex > > data structures just before exit, which is wasteful. > > I think it may be a bit presumptuous to call cleanup wasteful. > > Proper cleanup