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 libc/12650] New: Memory leak with dlopen() and thread-local storage variables


http://sourceware.org/bugzilla/show_bug.cgi?id=12650

           Summary: Memory leak with dlopen() and thread-local storage
                    variables
           Product: glibc
           Version: 2.13
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: robert.rex@exasol.com


Created attachment 5652
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5652
Possible patch to fix described memory leak

See this thread: http://sourceware.org/ml/libc-help/2011-04/msg00000.html

A memory leak occurs when executing the following steps:
(1) A program opens a shared library object with dlopen().
(2) A new thread is created (pthread_create()).
(3) The thread calls a function of the shared library which references a
thread-local storage variable.
(4) The function returns and the thread exits.

(my attached test case repeats steps 2-4 10000 times for a better
demonstration)

-> Result: The thread-local storage variable has been created via
___tls_get_addr() for each thread, but nothing is deallocated.
This only happens in case the dynamic library has been loaded by
dlopen() and not "directly" at load time.
I reproduced this issue with glibc in version 2.13 (but older versions seem
also to be affected [I also used CentOS 5.5, Ubuntu 10.10 [EGLIBC] and some
Debian system]).

Valgrind confirms this assumption:

# valgrind --leak-check=full ./test
[...]
==18274== HEAP SUMMARY:
==18274==     in use at exit: 41,114 bytes in 10,005 blocks
==18274==   total heap usage: 10,012 allocs, 7 frees, 42,196 bytes allocated
==18274==
==18274== 39,996 bytes in 9,999 blocks are definitely lost in loss
record 7 of 7
==18274==    at 0x4024DB9: memalign (vg_replace_malloc.c:581)
==18274==    by 0x401119B: tls_get_addr_tail (dl-tls.c:529)
==18274==    by 0x4011689: ___tls_get_addr (dl-tls.c:767)
==18274==    by 0x402B5B6: ???
==18274==    by 0x45B7CC8: start_thread (pthread_create.c:304)
==18274==    by 0x411269D: clone (clone.S:130)
==18274==
==18274== LEAK SUMMARY:
[...]

I attached a possible patch that fixed the leak for me. Before re-initializing
the TLS in get_cached_stack() it runs through the appropriate DTV and
deallocates all memory blocks.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- 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]