This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12650] New: Memory leak with dlopen() and thread-local storage variables
- From: "robert.rex at exasol dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 7 Apr 2011 14:05:06 +0000
- Subject: [Bug libc/12650] New: Memory leak with dlopen() and thread-local storage variables
- Auto-submitted: auto-generated
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.