[PATCH v2] malloc: Fix tcache leak on thread destruction [BZ #22111]
DJ Delorie
dj@redhat.com
Tue Oct 3 01:36:00 GMT 2017
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.
More information about the Libc-alpha
mailing list