[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#793641: glibc: too few static TLS slots

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.

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?


[1] https://sourceware.org/glibc/wiki/Release/2.22

Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Reply to: