static TLS exhausted on ppc64le

Florian Weimer fweimer@redhat.com
Tue Oct 22 13:39:00 GMT 2019


* Dan Horák:

> On Mon, 30 Sep 2019 16:02:12 +0200
> Dan Horák <dan@danny.cz> 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
>
> and it strikes again, after MPFR upgrade in Rawhide from v3 to v4 last
> week. Since then ppc64le and (probably also) aarch64 are
> uninstallable in Rawhide :-( MPFR increased its TLS usage
> significantly (0xf8 vs 0x364). If I understood the previous discussion
> right, then there are some options how to fix the problem. Is there any
> outline, when such fix might be available? It would be difficult for
> Fedora to roll back everything to MPFR 3.

I don't know what glibc can do here.  Jakub has said that he wants
libgomp to keep using initial-exec TLS.  The POWER maintainers want to
keep the optimization that consumes the static TLS area even for dynamic
TLS.  So there isn't much we can do on the glibc side.

Thanks,
Florian



More information about the Libc-alpha mailing list