Bug#793641: glibc: too few static TLS slots
On 2015-11-23 13:04, Aurelien Jarno 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.
>
> 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?
I have just tried to build master and the problem is also there, so the
answer is likely no.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: