Bug#793641: glibc: too few static TLS slots
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.
Without Alex's fixes the implementation is limited, by a heuristic, to
a limited number of libraries with STATIC_TLS, and after Alex's fixes
(available in glibc 2.22) the limit is "You may load as many
STATIC_TLS libraries as long as you have static image space for all of
them" (which is a much higher arbitrary limit).
Cheers,
Carlos.
Reply to: