This is the mail archive of the
mailing list for the glibc project.
Re: static TLS exhausted on ppc64le
On Mon, Sep 30, 2019 at 02:14:46PM +0000, Szabolcs Nagy wrote:
> 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/libgomp.so.1: 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.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1722181
> > https://bugzilla.redhat.com/show_bug.cgi?id=1738752
> > 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 libgomp.so.1, gcc should not build
> broken dsos by default (unless it can ensure they are never
> loaded dynamically):
> (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.
I'm strongly in favor of such a change. I'd also like to propose that
glibc deprecate dlopen of libraries with initial-exec access to their
own TLS and set an EOL for it. While the GCC stuff can be fixed
without doing that, GPU vendors are going to keep doing this until