This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug malloc/22111] malloc: per thread cache is not returned when thread exits


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]