Hi Bruno,
> Le 16 févr. 2020 à 13:52, Bruno Haible a écrit :
>
> Hi Akim,
>
> Sorry for the delay.
You look busy :)
>> +void
>> +fstrcmp_free (void)
>> +{
>> + gl_once (keys_init_once, keys_init);
>> + gl_tls_key_destroy (buffer_key);
>> + gl_tls_key_destroy (bufmax_key);
>> +}
>
> This
Paul Eggert wrote:
> it's merely choosing a point in a design space that involves simplicity,
> efficiency, correctness, testability, etc. and where there are several
> reasonable choices.
Right. In the case of fstrcmp, the bison tests use 'valgrind -q'. Akim could
use 'valgrind -q --leak-check=
On 2/16/20 12:44 PM, Jeffrey Walton wrote:
The coding standard is wrong in this area. The practice breaks testing.
Not really. It breaks some tests, which are arguably testing the wrong thing.
Any tests that check for whether all memory is freed just before exit, are
testing for a property th
On Sun, Feb 16, 2020 at 7:53 AM Bruno Haible wrote:
>
> ...
> > I agree, I would like to be able to explicitly release the memory. But
> > I can't see any API to do that in fstrcmp.c. Is this one ok?
>
> The GNU Coding Standards [1] tell us to not worry about this situation.
> However,
> the al
Hi Akim,
Sorry for the delay.
> > Do the threads still exist at the moment valgrind does its inventory of
> > left-
> > over memory?
>
> I don't know when it runs its stuff, but I expect, given where it stands,
> that it does it as the latest possible instant.
>
> > In particular:
> > - Did y
Hi all,
> Le 22 janv. 2020 à 07:50, Akim Demaille a écrit :
>
> I agree, I would like to be able to explicitly release the memory. But
> I can't see any API to do that in fstrcmp.c. Is this one ok? I feel
> stupid to initialize the memory right before releasing, but I didn't
> find a means to
Hi Bruno,
> Le 20 janv. 2020 à 22:57, Bruno Haible a écrit :
>
>>> 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
Hi Akim,
> > +==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==
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/msg6.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 d
