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 attachment 46301 [details, diff] 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 attachment 53527 [details, diff] 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 attachment 58456 [details, diff] 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 attachment 61823 [details, diff] Patch adapted from Fedora 1.49-1.50 cvs libc fix
Created attachment 61824 [details, diff] 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.
