This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: dlopen()/__thread behaviour
- From: Ryan Arnold <ryan dot arnold at gmail dot com>
- To: robert dot rex at exasol dot com
- Cc: libc-help at sourceware dot org
- Date: Fri, 1 Apr 2011 07:40:18 -0500
- Subject: Re: dlopen()/__thread behaviour
- References: <4D9564A1.5000302@exasol.com>
On Fri, Apr 1, 2011 at 12:37 AM, <robert.rex@exasol.com> wrote:
> Hi all,
>
> I was recently analyzing some memory leak for a project and tracked it
> down to the following (maybe uncommon) test case attached to this email.
>
> In short, the leak occurs in the following situation:
> (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 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 on several platforms (CentOS 5.5, Ubuntu 10.10
> [EGLIBC] and some Debian system).
Hi Robert,
There is indeed an accounting bug that we saw for PowerPC if GLIBC is
compiled -O3. The TLS blocks are aligned and more storage is
allocated than dlclose () is able to account for. The dlclose code
gets confused and isn't able to free the storage.
Alan Modra has provided a fix to libc-alpha for the TLS_DTV_AT_TP case
(use for PowerPC). No one has provided a similar fix for the the
TLS_TCB_AT_TP case (Used for some other architectures):
http://www.cygwin.com/ml/libc-alpha/2011-03/msg00021.html
This patch has not yet been committed.
I'm not sure if this effects other architectures without GLIBC being
compiled under higher optimization.
Ryan S. Arnold