Re: Leak Sanitizer - how to suppress leaks

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

Warner Losh wrote in <CANCZdfqTBj_0FwBbOLeu6fK9LX8UsVBnuJQDUfVOLJSP=tGc-\
A%mail.gmail.com@localhost>:
 |On Thu, Sep 12, 2019, 7:24 PM Simon Burge <[1]simonb%netbsd.org@localhost[/1]> wrote:
 |
 |  [1] mailto:simonb%netbsd.org@localhost
 |
 ||Kamil Rytarowski wrote:
 |
 ||> I will revert it, but I am looking for a more generic approach.
 ||>
 ||> How about adding ifdef __NO_LEAKS like:
 ||>
 ||> #ifdef __NO_LEAKS
 ||> free(3)?
 ||> #endif
 ||>
 ||> And in lsan/asan/valgrind/etc checks use -D__NO_LEAKS.
 |
 ||Sorry if I'm missing something that has been already explained,
 ||but why (practically) do we care about memory leaks for a utility
 ||that is about to finish?
 |
 ||If we're doing some ugly #ifdef dance only when running the
 ||sanitiser(s), then we haven't actually done anything to "fix"
 ||the leak in the installed binaries so it seems that there was
 ||no practical problem that we were trying to solve in the first
 ||place.
 |
 |When multiple people are doing leak busting, maybe over years, they \
 |eliminate many false positives so you can focus on the real issues \
 |w/o a run time penalty. Especially something in the library that 
 |comes up often... otherwise they get in the way of making progress...

Also overall i found it results in better design.  I had atexit
and atexit_final and with debug enabled _start could call
(in-library) main several times in a row without causing leaks or
any other problems, since anything would have been correctly
destructed.  (Not using constructor or destructor nor any other
ELF attributes.)  It is much nicer to see "Memory cache is
entirely empty.", than not.  Imho.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)