This is the mail archive of the
mailing list for the glibc project.
Re: static TLS exhausted on ppc64le
* Szabolcs Nagy:
> 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
> loaded dynamically):
I like the simplicity of initial-exec TLS.
I think there was a change on POWER to use the static TLS reservation
for dynamic TLS, as an optimization. Obviously, that's going to hurt
those cases where a library with initial-exec TLS is loaded late, even
if the static TLS reservation would ordinarily be large enough.