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?
Thanks,
Aurelien
[1] https://sourceware.org/glibc/wiki/Release/2.22
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: