This is the mail archive of the libc-help@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]

Re: dlopen()/__thread behaviour


On Fri, Apr 1, 2011 at 7:40 AM, Ryan Arnold <ryan.arnold@gmail.com> wrote:
>> -> 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):
> ...
> Ryan S. Arnold

Hi Robert,

I just ran your testcase against a GLIBC with Alan's patch on PowerPC
and Valgrind is still detecting the leak so there may be additional
leaks.

Ryan S. Arnold


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]