[Bug libc/11787] Program with large TLS segments fail.

["david.abdurachmanov at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=11787

--- Comment #39 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
The same test case fails on glibc 2.5 (RHEL 5.10), but that is expected. I have
an application, which dlopens plugins. It happens to be that dlopen fails with
new plugins, "cannot allocate memory in static TLS block".

I found some big TLS segments, e.g., 1296, 498, and 3068448. It happens that
plugins consumes 3+MB of TLS.

Looking at glibc 2.5 code, TLS size seems to be 1664+ bytes. I used private
symbol, _dl_get_tls_static_info, to get some information about TLS from plugin
manager and it always returned 3760 as TLS size. I did not manage to find a way
to get _dl_tls_static_used.

I do assume "cannot allocate memory in static TLS block" is related to huge TLS
segments size. It most likely doesn't fit into TLS space. Is there a quick way
to confirm this, or I need to debug dynamic loader?

glibc Release/2.18 wiki: https://sourceware.org/glibc/wiki/Release/2.18
In "1.2. Desirable this release?":

BZ#11787 - Programs with large TLS segment fail (Carlos)
A workaround here is going to be to use Siddhesh's new
LIBC_PTHREAD_DEFAULT_STACK_SIZE env var to bump up default stack sizes.

The fix is not in 2.18 as I understood, any progress for 2.19?

-- 
You are receiving this mail because:
You are on the CC list for the bug.