Bug#793641: glibc: too few static TLS slots
On Mon, Nov 23, 2015 at 7:04 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On 2015-08-17 15:04, Carlos O'Donell wrote:
>> On Sun, Aug 16, 2015 at 12:48 PM, Andreas Cadhalpun
>> <andreas.cadhalpun@googlemail.com> wrote:
>> >> until there's a better tested and working way to transition
>> >> to ffmpeg?
>> >
>> > This really doesn't have that much to do with the transition to ffmpeg.
>> > Any other library that (indirectly) links against sufficiently many
>> > STATIC_TLS using ones and is used in some plugin is also affected.
>> >
>> > Note that there are currently 14 STATIC_TLS slots and gst-libav uses 6,
>> > while it used 4 previously. It is a mere coincidence that this increase
>> > causes totem to hit the arbitrary limit in glibc.
>>
>> The math can't be done that easily, it's actually a heuristic, but
>> pretend it works this way for the sake of this discussion.
>>
>> The only immediate solution is for debian's glibc to increase
>> DTV_SURPLUS to 32 or higher. This is exactly what I did for Fedora.
>>
>> The other alternative is to backport Alex's fixes for Sourceware bugs
>> BZ #17090, BZ #17620, BZ #17621, BZ #17628, which corrects the
>> heuristics behind DTV_SURPLUS which prevent the loading of STATIC_TLS.
>
> I have backported these patches to 2.21. Unfortunately they now cause
> nptl/tst-cancel24-static to fail on at least armhf, armel, mips and
> mipsel. The binary segfaults.
Please submit a bug for this.
Is it segfaulting when accessing locales for the first time in the
newly dlopen'd libc.so.6?
There are several known issues regarding statically linked and
dlopened binaries that may impact this.
> According to the wiki [1], the failure seems to be a known issue
> in the 2.22 release, though its cause was marked as unknown. Do you know
> by chance if the problem has been fixed or addressed in the meantime?
No, nobody has fixed this upstream.
Any triage you can provide would be appreciated.
Cheers,
Carlos.
Reply to: