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

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