fstrcmp: memory is not reclaimed on exit

[Akim Demaille]

Hi!

There was a recent bug report about Bison not reclaiming all its
memory on exit (https://lists.gnu.org/r/bug-bison/2020-01/msg00006.html).
This is a not a leak, the memory is still reachable, yet we try to
stay clean on exit.  The traces from Valgrind are:

> 10. input.at:331: testing Symbol declarations ...
> ./input.at:369: COLUMNS=1000; export COLUMNS;  bison --color=no -fno-caret 
> -Wno-other -S./dump-symbols.m4 input.y
> --- /dev/null 2019-11-30 17:07:08.851263387 +0000
> +++ 
> /home/tkloczko/rpmbuild/BUILD/bison-3.5/tests/testsuite.dir/at-groups/10/stderr
>    2020-01-08 19:14:17.284197849 +0000
> @@ -0,0 +1,29 @@
> +==2837387== 320 bytes in 1 blocks are still reachable in loss record 1 of 1
> +==2837387==    at 0x483A80B: malloc (vg_replace_malloc.c:309)
> +==2837387==    by 0x117CFC: xmalloc (xmalloc.c:41)
> +==2837387==    by 0x11B743: UnknownInlinedFun (xalloc.h:103)
> +==2837387==    by 0x11B743: fstrcmp_bounded (fstrcmp.c:208)
> +==2837387==    by 0x142DED: UnknownInlinedFun (symtab.c:350)
> +==2837387==    by 0x142DED: UnknownInlinedFun (symtab.c:365)
> +==2837387==    by 0x142DED: UnknownInlinedFun (symtab.c:608)
> +==2837387==    by 0x142DED: UnknownInlinedFun (symtab.c:1017)
> +==2837387==    by 0x142DED: check_and_convert_grammar (reader.c:792)
> +==2837387==    by 0x1113E5: UnknownInlinedFun (reader.c:722)
> +==2837387==    by 0x1113E5: main (main.c:104)
> +==2837387== 
> +{
> +   <insert_a_suppression_name_here>
> +   Memcheck:Leak
> +   match-leak-kinds: reachable
> +   fun:malloc
> +   fun:xmalloc
> +   fun:UnknownInlinedFun
> +   fun:fstrcmp_bounded
> +   fun:UnknownInlinedFun
> +   fun:UnknownInlinedFun
> +   fun:UnknownInlinedFun
> +   fun:UnknownInlinedFun
> +   fun:check_and_convert_grammar
> +   fun:UnknownInlinedFun
> +   fun:main
> +}
> 10. input.at:331: 10. Symbol declarations (input.at:331): FAILED 
> (input.at:369)

which points to fstrcmp's allocation of its per-thread internal buffer.

AFAICT, glthread takes care of reclaiming the memory when the thread
exits, that's the whole point of the "free" in the first line of the
body here:

> static void
> keys_init (void)
> {
>   gl_tls_key_init (buffer_key, free);
>   gl_tls_key_init (bufmax_key, NULL);
>   /* The per-thread initial values are NULL and 0, respectively.  */
> }

glthread/tls.h reads

>      Initialization:            gl_tls_key_init (name, destructor);
> 
>    A destructor is a function pointer of type 'void (*) (void *)', called
>    when a thread exits, and taking the last per-thread value as argument.  It
>    is unspecified whether the destructor function is called when the last
>    per-thread value is NULL.  On some platforms, the destructor function is
>    not called at all.

I can see that it's not expected to work on some platforms, but in the
case of the user the platform is fairly mainstream:

> ## --------- ##
> ## Platform. ##
> ## --------- ##
> 
> hostname = barrel
> uname -m = x86_64
> uname -r = 5.3.12-300.fc31.x86_64
> uname -s = Linux
> uname -v = #1 SMP Thu Nov 21 22:52:07 UTC 2019

So I don't know what to do.  Is this a red herring related to Valgrind
as a platform?  Is this something else?  I found nothing interesting
about "glthread valgrind" etc. on web, sorry if I missed something.

Thanks!