This is the mail archive of the 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: static TLS exhausted on ppc64le

On 30/09/2019 15:02, Dan Horák wrote:
> Hi,
> I would like to open a problem we have already met twice in Fedora. the
> symptom is
> "/lib64/ cannot allocate memory in static TLS block"
> usually when loading a lot of libraries/modules into a Python
> application. It happened on ppc64le and also on aarch64 systems.
> We have 2 reports in Fedora bugzilla about with more details.
> We have already discussed that briefly with Florian and other members of
> the Red Hat toolchain team, but outcome was in form of a recommendation
> to reduce the usage of "static TLS" objects in the individual libraries.
> But the open question still is - is there a fix for the TLS space
> exhaustion? I believe it can easily become a more serious problem soon.

(a workaround is preloading the problematic libs at startup time)

i think it's a bug in, gcc should not build
broken dsos by default (unless it can ensure they are never
loaded dynamically):;a=blob;f=libgomp/configure.tgt;h=b88bf72fe3de3735929635c874b8da375c841b1d;hb=HEAD#l13

(libitm has a similar hack)

e.g. this is patched out manually when building a musl libc
based toolchain since musl does not reserve static tls for
broken dsos.

i would support removing such hacks from gcc target libs
(or at least hide it behind some obscure config option),
but i guess that should be discussed with gcc maintainers
and not on libc-alpha.

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