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

[DJ Delorie <dj at redhat dot com>]

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.

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