This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: static TLS exhausted on ppc64le


On Tue, 22 Oct 2019 16:51:00 +0000
Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:

> On 22/10/2019 15:01, Dan Horák wrote:
> > 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.
> 
> i did not see any objection to the first step in
> https://sourceware.org/ml/libc-alpha/2019-09/msg00533.html
> 
> nor to my even simpler suggestion in
> https://sourceware.org/bugzilla/show_bug.cgi?id=25051
> 
> so i think there is a way forward (i just don't have the
> time right now to submit a patch, i can look into it a
> bit later ~1-2 months if nobody beats me to it).

thanks in advance, in the meantime I'll propose a workaround for the
installer, I have confirmed that starting anaconda with
LD_PRELOAD=libgomp.so.1 makes it run.

> > 
> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]