Bugzilla Bug 52374

Gxine 0.3.3 refuses to work.

gxine server: trying to connect to already running instance of gxine (/root/.gxine/socket)...
connect: Connection refused
server: socket '/root/.gxine/socket' created
Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!

Portage 2.0.50-r7 (default-x86-1.4, gcc-3.4.0, glibc-2.3.3_pre20040420-r0, 2.6.6-love4)
=================================================================
System uname: 2.6.6-love4 i686 AMD Athlon(TM) MP 2400+
Gentoo Base System version 1.4.15
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=athlon-mp -funroll-loops -fomit-frame-pointer -pipe -ftracer -ffast-math"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=athlon-mp -funroll-loops -fomit-frame-pointer -pipe -ftracer -ffast-math"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="ftp://ftp.easynet.nl/mirror/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow X alsa apm avi berkdb bonobo crypt cups curl directfb encode esd evo faad fbcon ffmpeg flac fltk foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 guile imlib java jpeg ldap libg++ libwww live mad mikmod mmx motif mozilla mpeg mpeg4 ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang spell sse ssl svga tcltk tcpd tiff truetype usb wmf wmv x86 xine xinerama xml2 xmms xv zlib"

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

The error also exists with gcc 3.4.0-r5 and a recompile of xine-lib and gxine.

The root cause of this is ABI incompatibilities stemming from the USE=nptl on
x86_64 (amd64).

last comment was over two months ago.  Do we have a solution or not?

I still have this problem and don't use x86_64. I have USE="ntpl" the newest
(~86) glibc, gcc, xine-lib etc.

What I've tried:

emerge -C gettext libvorbis win32codecs divx4linux libdvdcss alsa-lib
pkgconfigflac libsdl libfame xvid libtheora speex xine-lib codeine

emerge gettext libvorbis win32codecs divx4linux libdvdcss alsa-lib pkgconfig
flac libsdl libfame xvid libtheora speex xine-lib codeine -v

This was suggested in the forums to solve the problem but it still exists here.

root@inspiron> emerge info                     /usr/portage/media-video/codeine
Portage 2.0.51-r3 (default-x86-2004.2, gcc-3.4.3, glibc-2.3.4.20041102-r0,
2.6.8-ck7 i686)
=================================================================
System uname: 2.6.8-ck7 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.40GHz
Gentoo Base System version 1.6.6
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.92.0.2-r1
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r6
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=pentium3 -mtune=pentium4m -Os -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium3 -mtune=pentium4m -Os -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache distlocks fixpackages sandbox"
GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
http://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://mir.zyrianes.net/gentoo/
http://mir.zyrianes.net/gentoo/ http://www.gigaload.org/gentoo.org/
ftp://ftp.easynet.nl/mirror/gentoo/ ftp://gd.tuwien.ac.at/opsys/linux/gentoo/
http://ftp.easynet.nl/mirror/gentoo/
ftp://ftp.tu-clausthal.de/pub/linux/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X acpi alsa ansi auctex audiofile avi berkdb bitmap-fonts bzlib
cdparanoiacdr crypt cups dio dvd emacs encode faac faad flac flood freetype ftp
gdbm gif gnutls gpm gprof graphviz gstreamer gtk gtk2 icq imagemagick imap
imlib imlib2 ipv6 ithreads jabber jack jack-tmpfs java javascript jikes jpeg
jpeg2k kde libwwwlive mad mikmod mmx mmx2 mng motif mozxmlterm mpeg ncurses
network nls no_wxgtk1 nptl offensive oggvorbis openal opengl pam pcmcia pdflib
pic png pnp qt quicktime readline real rtc ruby sdl slang slp speex sse ssl svg
tcpd tetex theora threads tidy tiff truetype type1 unicode usb videos wmf
wxwindows x86 xine xml2 xpmxprint xv xvid zlib linguas_de"

I have this problem as well with xine, on ~x86 (intel) with nvidia drivers.

There is some more information about this, including apparently a way to reproduce it in the last post at 

https://bugzilla.ubuntu.com/show_bug.cgi?id=1724

Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r3 i686)

This is a glibc bug, look at the output of:

strace -e open xine

Last line just before crapping out:

open("/usr/lib/libGLU.so.1", O_RDONLY)  = 6
open("/usr/lib/opengl/nvidia/lib/libGLcore.so.1", O_RDONLY) = 6
open("/usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so.1", O_RDONLY) = 6
Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!

Looks like dlopening the Nvidia driver with tls support makes it crap out.

Can you verify the above on your systems.

Same result here

I just did a test after reading the last post.  I ran opengl-update xorg-x11. 
Then I ran xine with no problems, whereas before a was getting this same error.
 I'm running nvidial drivers 1.0.6111.  I'm also using "nptl".

sloan

Same result, but it  seems to get only with xine (and relatet apps like
pornview and vlc), other media-apps work. And the opengl-update works.

Here is my strace-output

open("/usr/lib/libGLU.so.1", O_RDONLY)  = 8
open("/usr/lib/opengl/nvidia/lib/libGLcore.so.1", O_RDONLY) = 8
open("/usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so.1", O_RDONLY) = 8
Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72:
_dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx'
failed!

BTW: What this tls-support, I never heard of it.

I get the exact same results. opengl-update xorg-x11 is a valid workaround.
Here is my emerge info:

Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4,
glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r6 i686)
=================================================================
System uname: 2.6.9-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz
Gentoo Base System version 1.6.7
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.90.0.1.1-r3
Headers: 
sys-kernel/linux26-headers-2.6.8.1,sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/
http://distro.ibiblio.org/pub/Linux/distributions/gentoo/
ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://gentoo.mirrors.pair.com/
ftp://mirrors.tds.net/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="3dnowex S3TC X aalib acpi aim alsa apm ared aredmem arts audiofile avi
berkdb bindist bitmap-fonts bzlib cdinstall cdparanoia cdr crypt cups dbm
directfb divx4linux doc dvd dvdread encode esd ethereal exif f77 fam fbcon
fbdev fdftk flacfoomaticdb fortran freetype fs ftp gdbm gif gimp gimpprint glut
gnokii gnome gpm graphviz gs gstreamer gtk gtk2 gtkhtml icq imagemagick imap
imlib ipv6 java javascript jikes jp2 jpeg jpeg2k kde kerberos krb4 ldap libg++
libwww lzw lzw-tiff mad maildir mikmod mime mmx motif mozcalendar mozdevelop
mozilla mozsvg mozxmlterm mpeg mplayer ncurses net network nls nodroproot nptl
nvidia offensive oggvorbis ooo-kde opengl oscar oss pam pda pdf pdflib perl pic
png posix python qdbm qt quicktime readline recode rtc samba scanner sdl slang
sndfile sockets socks5 speedo spell sqlite sse ssl svg svga tcltk tcpd threads
tiff tokenizer truetype type1 usb vim-with-x wifi wxwindows x86 xchattext xface
xine xml xml2 xmms xosd xpm xprint xscreensaver xsl xv xvid yahoo zlib"

So apparently this is to do with the nvidia drivers needing fast thread-local
storage (TLS) for OpenGL thread support, and messing with registers they don't
have a right to. Leastways, that's what I gather from this thread:
http://lists.freebsd.org/pipermail/freebsd-threads/2003-June/000530.html

(Kids, this is why closed code is A Bad Thing.)

Now, I only get the bug with vlc - not with gxine etc., unlike some. This
suggests a possible workaround may be to experiment with CFLAGS and USE flags.
Anyone up for it?

Another workaround that WFM is to use
LD_PRELOAD=/usr/lib/opengl/nvidia/lib/libGL.so.1:/usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so.1
- it seems loading the nvidia TLS early on prevents the bug showing up. Either
put it in your environment or write wrappers for affected apps.

*** Bug 74413 has been marked as a duplicate of this bug. ***

Or apparently not - read
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219352#msg122 and try the test
case there.

This suggests that the success or failure is due to supplementary libraries
(plugins to vlc, xine-lib, etc) not being available. This interpretation is
strengthened by the fact that LD_PRELOAD works as a workaround, changing the
order of loading libraries, in accordance with the analysis in the link.

(Speculation: something is not being cleaned up correctly when a library
dependency is unfulfilled.)

So this is not a nvidia bug, it is a glibc/ld bug and nvidia/tls is just the
trigger.

Please reassign to the glibc maintainers.

Further information:

The analysis on the debian bug is correct. When the plugin library fails to find its library dependencies it is unloaded and the thread-local variable dl_tls_dtv_gaps is set to TRUE to mark that the dtv array may have holes:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/elf/dl-open.c?rev=1.116&content-type=text/x-cvsweb-markup&cvsroot=glibc&only_with_tag=MAIN
(line 620, _dl_open())

Unfortunately dl-tls.c assumes incorrectly that dl_tls_dtv_gaps is never set to TRUE at program startup, leading to some incorrect code caught by the assertion:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/dl-tls.c?rev=1.44&content-type=text/x-cvsweb-markup&cvsroot=glibc
(line 65 onwards, _dl_next_tls_modid())

I'm currently compiling with the obvious fix:
-      /* If the following would not be true we mustn't have assumed
-        there is a gap.  */
-      assert (result <= GL(dl_tls_max_dtv_idx));
+      /* If the following is true we shouldn't have assumed there is a gap.  */
+      if (result > GL(dl_tls_max_dtv_idx))
+         goto nogaps;

This is probably buggy though, it needs looking at by someone who understands the internals, either someone on the gentoo glibc team or if not upstream it to the glibc developers.

Created an attachment (id=46301) [details]
Suggested patch to glibc

This is the patch I settled on. It's an rcs diff against Gentoo
glibc-2.3.4.20041102.

It works, with vlc and with the testcase on the debian bts.

I think it may even be the correct patch, but it needs review by someone who
knows glibc/dl/tls internals better.

The LDPRELOAD fix allows me to start Totem again with the xinelib backend. But
there isn't any final solution yet?

@Ed Catmur

Very nice, finally xine runs w/o problems and openoffice-ximian, too, with nvidia glx being used. Nice patch!

good news :

i just installed nvidia-glx 6629-r1
and now, gxine launches, while previously it triggered this error

work-around or real fix ? (i did not touch/emerge glibc for a long time)

The bug is still there with sys-libs/glibc-2.3.4.20050125.

Ed Catmur's patch works for glibc-2.3.4.20050125 too.
I use that now for several days and haven't seen any ill effect.
Thanks for the patch.

I hope that it gets applied eventually.

Screw this, I've upstreamed it myself.

http://sources.redhat.com/bugzilla/show_bug.cgi?id=786 - let's see what happens.

Created an attachment (id=53527) [details]
glibc-2.3.4-fix-_dl_next_tls_modid-assert.patch

Yeah, sorry, was fairly inactive the last year and a half.  Anyhow, here is the
proper patch with all the context JJ left out - busy testing.

PS: its against 2.3.4.20050125 .. I'll check later how much effort it will be
to backport.

Yes, that fixes it for me as well. Thanks for taking this up.

The fix is also in 20050125-r1 which will be leaving package.mask soon

20050125-r1 fixed it for me as well. Thanks.

The current portage, glibc-2.3.5 seems to have broken this again.

I can confirm glibc 2.3.5 has the problem back, but looking at the ebuild the
patch (or its equivalent) is not applied. The old one from 2.3.4 does not apply
cleanly though...

We need to apply this diff (off the RH glibc cvs):

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/dl-tls.c.diff?r1=1.49&r2=1.50&cvsroot=glibc

Yes, it's from March 20th - guess 2.3.5 was rolled quite a while ago.

Indeed, all fixes from the 2.3.4 patch were applied in 2.3.5 except for this
one.

I have edited the patch to apply cleanly to 2.3.5, and everything works fine
again (it may be better to keep the additional test case in the ebuild if the
patch is applied)

Created an attachment (id=58456) [details]
glibc-2.3.5-fix-_dl_next_tls_modid-assert.patch

Adapted from 2.3.4 patch

I have just experienced this bug when trying to run Totem and Kaffeine with
glibc 2.3.5 AMD64 system.

Open Office 2 32bit binary is also affected on amd64 (see
http://forums.gentoo.org/viewtopic-p-2442616.html)

Created an attachment (id=61823) [details]
Patch adapted from Fedora 1.49-1.50 cvs libc fix

Created an attachment (id=61824) [details]
patch to add line to glibc-2.3.5.ebuild

These two patches fixed the problem when I used them in my portage overlay. 
Open Office 2 beta works now.  This was taken strait from the Fedora/RedHat CVS
update page refrenced by Ed above.  I have not tested it much yet so I am not
sure what it all breaks or fixes.

*** Bug 93880 has been marked as a duplicate of this bug. ***

the patch is in cvs and will be in 2.3.5-r1

*** Bug 100897 has been marked as a duplicate of this bug. ***

In 2.3.5-r1.