Re: memory leaks in gnulib tests (for ASAN/LINT)

[Bruno Haible]

Hi Tim,

There is no way to avoid not-serious memory leaks in the long run.
  1) There are API functions like bindtextdomain(), textdomain()
     which are supposed to keep information until the process terminates.
  2) There are certain tasks like reading an initialization file (think
     of ~/.wgetrc), that are also keep the allocated settings in memory
     until the end of the process.
  3) There are caches. Glibc has some caches (e.g. in gettext()). Gnulib
     has some caches (e.g. in localename).

Are there APIs to undo these memory allocations? reset_textdomain?
free_all_settings? clear_gettext_cache? No, because when you know that the
OS cleans up the entire process space anyway, programmers don't want to
spend time creating such APIs. (Programmers for embedded devices without
an OS might have different habits. But that's not the target of Gnulib nor
of GNU.)

So, these not-serious memory leaks will stay.

Do you think 'wget' testing with valgrind/ASAN should be limited to
situations without i18n and without initialization file? I would think
it's essential to test 'wget' also with i18n and with an initialization
file, since many users will use it this way.

> onto *manual* separating the serious from the harmless reports.

I encourage you to find automated ways to separate the serious from the
harmless memory leaks.

One approach is repetition. See tests/test-fprintf-posix3.c for an example.

The other approach I am aware of are suppression files.

> with 100 such tools we (or the people who care) would need to
> write and maintain 100 exception files. This is simply not reasonable.

Then you (or the people who care) should make an effort to standardize
the suppressions file format. So that a suppression created for valgrind
can be reused with ASAN, and vice versa.

> Even if no one here has time to do so, we should encourage people like
> Assaf to at least report these issues

I welcome and encourage all reports about valgrind/ASAN findings regarding
invalid or unaligned pointer accesses, uninitialized memory or conditions,
and serious memory leaks.

Bruno