Bug#793641: glibc: too few static TLS slots
Hi,
On 16.08.2015 17:12, Andreas Henriksson wrote:
> Thanks for your interest in this issue.
You're welcome.
> On Sun, Jul 26, 2015 at 09:35:16PM +0200, Andreas Cadhalpun wrote:
>> Control: severity 793641 important
> [...]
>
> I'd like to start out with questioning this.... gstreamer1.0-libav
> is completely unuable now, breaking very popular programs like totem.
> Severity should in my opinion be grave.
The severity had been normal originally so I increased it.
I didn't chose grave, because this bug doesn't make glibc unusable.
You can adjust the severity, if you think that is appropriate,
but arguing about bug severity is usually not helpful.
> [...]
>> The link [1] provided there is quite helpful.
> [...]
>> 1: https://bugzilla.redhat.com/show_bug.cgi?id=1124987
>
> It indeed is, and I'd like to point out comment #22:
>
> "
> For the record it is not a glibc bug. It is a defect in the loaded
> libraries, they should not require TLS. Fundamentally it's a defect
> that we allowed developers to build shared libraries with static TLS
> in the first place.
> "
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1124987#c22
Then let me also point out form comment #15:
"> 108 /lib64/libgomp.so.1
- OK. May use STATIC_TLS, it's part of the implementation.
Language runtime support for gomp shared across all programs."
"> 0 /lib64/libcrypt.so.1
> 0 /lib64/libm.so.6
> 0 /lib64/libnsl.so.1
> 0 /lib64/libnss_files.so.2
> 0 /lib64/libpthread.so.0
> 0 /lib64/libresolv.so.2
> 0 /lib64/librt.so.1
> 0 /lib64/libutil.so.1
- OK, all part of the implementation (glibc)."
So it's not a bug in libgomp and libresolv and hence can only be fixed
in glibc.
> No matter if this is a bug in glibc or not, ffmpeg maintainers should
> take any 'temporary' measures at hand to ensure usability and not expect
> changes to be done on a whim to critical system components like glibc.
I had hoped that one of the glibc maintainers would comment on this bug,
before we resort to workarounds.
> This breakage has persisted way too long now.
However, surprisingly few people complained about it...
> If there are no other option,
As I wrote the other option would be to work around this bug by not linking
ffmpeg against some external libraries.
Can you confirm that removing --enable-libsoxr from ffmpeg's debian/rules
avoids this problem?
If not, also removing --enable-libssh should work.
> maybe it's time to start planning transitioning back to libav
No.
> 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.
> Speaking to #debian-multimedia there doesn't seem to
> be much interest in dealing with the breakage caused by the ffmpeg
> transition right now.
Since the bug is in glibc, only the glibc maintainers can fix it.
Best regards,
Andreas
Reply to: