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: Dan Horák <dan at danny dot cz>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>, Rich Felker <dalias at libc dot org>
- Date: Mon, 30 Sep 2019 14:14:46 +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=PLMxUEMQw/SKeH9282CbZNcltbPM9QLF1uW4KTobrno=; b=KjpopPq1bbgMuAz05PTlIE2ucfO2oBqAbWP9aNo8epRe1v1QqImmk2Hk6Z4PHHTnkS/qTjntaQrlcbSkgsG7fCMYBnHpNhD7JQa9+Kou+0Wvl7r0Sxc/OdYqAtMi2Ohd8b0N/aymDwl4FpjtoR9fiF4O8fDOUJWAOwwCOitdYEh/XF8VRUPtrEDIweEUC/GArG9wH+7DQX2bwL8ICycjCcwhDDpNE3AeEcp1zcCwxwPqQFXr6igKW9HGxL8cvsmUfoe2rxXuqD5p9/A/j7rKuDkZ5vc/wLzPS6qS0248EkNHdIOL6Kgvpoc7bvQIe87wYJb5ezplG72wco9LDQQ96w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rg4Z1scrHVMfdz5GktDchra0SVM+9s7jR3ZNFleZcOWGsyXP62MfQPEJGVHmMaidAg/a4L4MOR1jMNMvtYwaIuucF/eG5W25VM1RUGSx0dVtmMCko1SMJht1FkSg3ogBFV8/GAEwEwA+5c4SgJKYkDAjGeWPd71ZhgwgHMM+c3mvz9AlJpKUKkEoTsCMmLfh7iSUMGzgnot9T3OnzJsegRaXZUmaBtbgSIHtY9Gwmsgz3cx0yz8kGQOfzlvnZZpxZnZzDIPEmDeHnmcq7sk5l/SVK1JZsOKGWlCh9MyIlZeV/gTd6tMu7yRSvfujLec+OuLKa+QKLQcKmPM/Sv7NOw==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <firstname.lastname@example.org>
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
(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
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.