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!