[Bug malloc/22711] New: malloc: memory leak when exiting threads with pthread_detach

["hannes.kuettner at meinberg dot de" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22711

            Bug ID: 22711
           Summary: malloc: memory leak when exiting threads with
                    pthread_detach
           Product: glibc
           Version: 2.26
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: hannes.kuettner at meinberg dot de
  Target Milestone: ---

Created attachment 10746
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10746&action=edit
Test program and pmap logs

A test program that creates a few million threads, detaches them as soon as
they are created, and waits for their completion leaks memory with the new
per-thread malloc cache enabled by default in 2.26. 

I ran my test program with the newest version on the master branch.
Joining the threads in the test program does not leak memory, detaching them
however does.

When disabling the experimental malloc with --disable-experimental-malloc no
leaks are observed and the VmRSS stays constant.

With tunable glibc.malloc.tcache_count=0 (with should equal
--disable-experimental-malloc according to the documentation) the application
still leaks memory, though less than with the default options.

Using pmap (logs attached) one can see that there are multiple small allocated
memory blocks which size increases over time. Additionally there is one larger,
growing block which is only present with the default options but not when
executed with tcache_count=0.
Those memory allocations are not present when disabling the per-thread malloc.

Additional info:
Happens in: glibc 2.26-1 and glibc 2.26.9000 (tested up until commit
505d39100454b38c62a8eff4c1b7c06b4a31f3aa)

Steps to reproduce:
1) Compile attached file
2) Run it and simultaniously view memory usage with pmap -x
3) Run it again with GLIBC_TUNABLES=glibc.malloc.tcache_count=0 and compare
4) Run it with glibc with per-thread malloc cache disabled and compare


-- Hannes

-- 
You are receiving this mail because:
You are on the CC list for the bug.