This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: static TLS exhausted on ppc64le
On Tue, 22 Oct 2019 15:39:33 +0200
Florian Weimer <fweimer@redhat.com> wrote:
> * 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.
hm, are we stuck in a deadlock then? That's not good, we have already
met at least 3 incidents in Fedora that blow up with this
error :-( With Python3 involved in all of them.
Dan