This is the mail archive of the
mailing list for the glibc project.
Re: static TLS exhausted on ppc64le
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: nd <nd at arm dot com>, Dan Horák <dan at danny dot cz>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 30 Sep 2019 15:44:14 +0000
- Subject: Re: static TLS exhausted on ppc64le
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=os/wX3F54JsK5gruxfIYjFBO21yG54okYHfibYL9Y1U=; b=MzoNzuXpNAy286sKbLzVOJiHPTX6yYCmP1JIb8BqFElA9Jsr6J6wdYTsBvlaFLvJEyClVSl8HFqJ3P59SOZeOKDWoIoLhGkepMgALDYZAG/VWHkA/qp7coM0d/gaMqlwNy/3lsOOtAFFTEdYpMBcrs9mDSDE7TQlJYrQ2dFjltHzPcnQqTbwee0TeGW3graj4lBZ5LqDDo7CFu0M1l0ozAfrXTFLA9PvvA9TRZVxPCkhyPOdL4y5QqD7Y9NQ7SEey5H+90Q3qcAsmxww0UPfPSRP7uqjoLqiBBH4gEZrIjpWZ0tmfiiIXJ4jbWAHC1fuRjG1qeu0H+QisHWRzuY9Sw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=il4iDOzA5dIrW16O+VTsnly9E2PY5ukFsFUi0EAXUDNQASfJAchuFYl8Rxa3OrqzTvi27uNfc2RjgguNFSChDoHQEwkH0sXyJdXhAa2dIejekKA9lGUKvWAvkwVbfecdcWkZ7YbMCLuA6R7uypPIdZZQZQaD/+yoJbniMHYyZJzo1JWBmvHUryJQjpWtSjQgpijGWB2tx3tmIzcM0fvHS3zQMJyYvOxd2Dgq6i7y5z4S/WAwblYzcnp22zeAPSDPJip+la5Z5gL6+p0z0gt9KkptYgLd5v7GfLbkd1WiHmt0ZtGuR1IMR7ALgXE5OkD4b3GkHClQIuwxnwHU02yQaQ==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <email@example.com> <firstname.lastname@example.org> <20190930142246.GO9017@brightrain.aerifal.cx>
On 30/09/2019 15:22, Rich Felker wrote:
> On Mon, Sep 30, 2019 at 02:14:46PM +0000, Szabolcs Nagy wrote:
>> On 30/09/2019 15:02, Dan Horák wrote:
>>> 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.
>>> 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
> it's hard-breaking.
created gcc bug
note: the aarch64 and powerpc64 only failures can
be fixed in glibc, but i'd prefer to fix this in gcc.