This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/22111] malloc: per thread cache is not returned when thread exits
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 06 Oct 2017 20:18:30 +0000
- Subject: [Bug malloc/22111] malloc: per thread cache is not returned when thread exits
- Auto-submitted: auto-generated
- References: <bug-22111-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=22111
--- Comment #10 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, release/2.26/master has been updated
via 6e1ea21501eac981204c3cc8212d45998f74983c (commit)
from dd3a7239fddff81ac31373d69978d7aa1902c65f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6e1ea21501eac981204c3cc8212d45998f74983c
commit 6e1ea21501eac981204c3cc8212d45998f74983c
Author: Carlos O'Donell <carlos@systemhalted.org>
Date: Thu Sep 28 11:05:18 2017 -0600
malloc: Fix tcache leak after thread destruction [BZ #22111]
The malloc tcache added in 2.26 will leak all of the elements remaining
in the cache and the cache structure itself when a thread exits. The
defect is that we do not set tcache_shutting_down early enough, and the
thread simply recreates the tcache and places the elements back onto a
new tcache which is subsequently lost as the thread exits (unfreed
memory). The fix is relatively simple, move the setting of
tcache_shutting_down earlier in tcache_thread_freeres. We add a test
case which uses mallinfo and some heuristics to look for unaccounted for
memory usage between the start and end of a thread start/join loop. It
is very reliable at detecting that there is a leak given the number of
iterations. Without the fix the test will consume 122MiB of leaked
memory.
(cherry picked from commit 1e26d35193efbb29239c710a4c46a64708643320)
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 9 +++
malloc/Makefile | 3 +
malloc/malloc.c | 8 ++-
malloc/tst-malloc-tcache-leak.c | 112 +++++++++++++++++++++++++++++++++++++++
4 files changed, 129 insertions(+), 3 deletions(-)
create mode 100644 malloc/tst-malloc-tcache-leak.c
--
You are receiving this mail because:
You are on the CC list for the bug.