This is the mail archive of the
libc-alpha@sourceware.org
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: <20190930160212.63aeb2bac0c9adf9eedcfbeb@danny.cz> <9170c628-6c99-d226-7328-ef99e4881e7b@arm.com> <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:
>>> 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):
>>
>> https://gcc.gnu.org/git/?p=gcc.git;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.
>
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
note: the aarch64 and powerpc64 only failures can
be fixed in glibc, but i'd prefer to fix this in gcc.