Created attachment 5652 [details]
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.