bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fstrcmp: memory is not reclaimed on exit


From: Bruno Haible
Subject: Re: fstrcmp: memory is not reclaimed on exit
Date: Mon, 20 Jan 2020 22:57:55 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; )

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==    by 0x11B743: fstrcmp_bounded (fstrcmp.c:208)
> 
> which points to fstrcmp's allocation of its per-thread internal buffer.

Correct. This is the per-thread 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:

Meanwhile this destructor stuff even works on native Windows. The list of
platforms where it does not work is very small (something like mingw with
winpthreads, IIRC).

> So I don't know what to do.  Is this a red herring related to Valgrind
> as a platform?

Do the threads still exist at the moment valgrind does its inventory of left-
over memory? In particular:
  - Did you create threads, in which fstrcmp is run? If yes, are they still
    running?
  - Or did you run fstrcmp in the main thread? Most likely valgrind does its
    inventory in the main thread, during exit(). This means that at this point
    the fstrcmp buffer for the main thread still exists. In other words, you
    should treat thread-local memory allocations for the main thread like
    static memory allocations (e.g. like in uniqstr.c).

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]