Re: [PATCH v2] malloc: Fix tcache leak on thread destruction [BZ #22111]

[Andrew Pinski <pinskia at gmail dot com>]

On Mon, Oct 2, 2017 at 6:36 PM, DJ Delorie <dj@redhat.com> wrote:
>
> Carlos O'Donell <carlos@systemhalted.org> writes:
>> diff --git a/malloc/tst-malloc-tcache-leak.c b/malloc/tst-malloc-tcache-leak.c
>> +void *
>> +worker (void *data)
>> +{
>> +  /* Allocate an arbitrary amount of memory that is known to fit into
>> +     the thread local cache (tcache).  If we have at least 64 bins
>> +     (default e.g. TCACHE_MAX_BINS) we should be able to allocate 32
>> +     bytes and force malloc to fill the tcache.  We have the allocated
>> +     memory escape back to the parent to be freed to avoid any compiler
>> +     optimizations.  */
>> +  return (void *) xmalloc (32);
>> +}
>
> This would be slightly more future-proof if it did an alloc/free/alloc
> cycle, in case in the future malloc doesn't init the tcache "just
> because".  The free would force the init, since the chunk would be
> stored in the tcache.
>
> Actually, a malloc/free might be a better test, since it tests that the
> free'd chunks in the tcache are freed as well as the tcache
> infrastructure itself.  Or maybe as a second test.

And if you are going to do a malloc/free pair, make sure you add a
compiler barrier in the code so the compiler does not delete the
malloc/free pairs (which it does already).

Thanks,
Andrew

>
> Also, some protection against user-environment tunables disabling the
> tcache might be appropriate, although that would only stop false
> positives.