GNOME Bugzilla – Bug 111349
libXi with XInitThreads is broken
Last modified: 2005-06-24 06:58:28 UTC
Simple test case, to save as test.c: #include <gtk/gtk.h> #include <X11/Xlib.h> int main (int argc, char **argv) { if (XInitThreads() == 0) { g_message ("XInitThreads() = 0"); return 1; } gtk_init (&argc, &argv); return 0; } Compile with the following line: gcc -O -o test test.c `pkg-config --libs --cflags gtk+-2.0` launch ./test, it returns within a second Compile with the following line: gcc -O -o test test.c `pkg-config --libs --cflags gtk+-2.0 gstreamer-0.6` launch ./test, and see it hang... Here's the backtrace from it:
+ Trace 36154
The output from ldd test: libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x40028000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x4027c000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x402ea000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x40304000) libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x40317000) libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40338000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40345000) libgstreamer-0.6.so.0 => /usr/lib/libgstreamer-0.6.so.0 (0x40378000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x403ea000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40420000) libdl.so.2 => /lib/libdl.so.2 (0x40424000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x40428000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4042d000) libz.so.1 => /usr/lib/libz.so.1 (0x40518000) libm.so.6 => /lib/tls/libm.so.6 (0x40526000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40549000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x405b3000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x405c1000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x406a0000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x406a4000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x406ad000) libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x406bb000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x406cd000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x406d5000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x406fa000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0x4074c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40754000) The output from pkg-config --cflags --libs gstreamer-0.6: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -I/usr/include/gstreamer-0.6 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -Wl,--export-dynamic -pthread -lgstreamer-0.6 -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lxml2 -lz -lm -lglib-2.0 This bug is marked as blocker as it makes the GStreamer version of Totem fail to even start.
This was tested on a RHL9 system with all the nice updates and the GStreamer 0.6.1 RPMs, it also happens on a Debian Sid PPC system with CVS 0.6.x HEAD.
It's a bug either in gtk+ or glibc 2.3.x (a behaviour change that would break gtk+ ?): Same test case, use with: gcc -O -o test test.c -pthread `pkg-config --cflags --libs gtk+-2.0` Remove -pthread and it will work properly. Tested with different compilers, both 2.96.x and 3.2.x break Tested with different kernels (and architectures) Tested with different glibc: works ok with a 2.2.x glibc Backtrace is still the same.
It's 99% certain to be a bug in the X libraries. I can't reproduce it though here on a stock RH9 system. The first step would be to get a copy of the XFree86 libraries with debugging information to get a better backtrace. (See: http://mail.gnome.org/archives/gtk-list/1999-January/msg00019.html which seems to be the same problem; though it was a little uncertain because the app in question was doing lots of somewhat questionable stuff.)
Here is the backtrace with debugging infos... Hope this helps.. gtk+-2.0 version 2.2.1 Xfree 4.3 (gdb) bt
+ Trace 36301
Well, what that indicates is that someone didn't _unlock_ the display, so the attempt to lock it again hangs. Which is going to be harder to debug; you'll basically have to put breakpoints in XLockDisplay() and XUnlockDisplay() and step through the init sequence until you find the point where the display is locked and then not unlocked.
Created attachment 16062 [details] locks debugging with debug X libraries
In the log above, the bug is pretty obvious. There is locking before around the library's init functions, and inside it. Owen, how do you propose we go about escalating this bug to the X people?
Looking at the source code for the X input module: http://cvsweb.xfree86.org/cvsweb/xc/lib/Xi/XListDev.c?rev=3.5&content-type=text/x-cvsweb-markup XListInputDevices seems to call LockDisplay a tiny bit too early: 1) _XiCheckExtInit will lock the display by itself 2) if the _XiCheckExtInit fails, the display isn't unlocked I suggest moving the LockDisplay call until after the _XiCheckExtInit call. Owen, can you see if that makes sense? If you think that's a good resolution to the problem, I'll close this bug and open a new bug with Red Hat and Debian to push the fix upstream.
Sorry for the spam
*** Bug 111880 has been marked as a duplicate of this bug. ***
Created attachment 16145 [details] [review] patch for XFree86 4.3.0
Close the bug. Point your XFree86 maintainer to this bug for a fix. It has already been sent to Red Hat, Debian and Mandrake.
Sorry to be slow on this, but I don't think the patch is at all correct, though I'd have to do more research to say what the right patch is. A) _XiCheckExtInit() is called from many, many other functions in exactly the same fashion. B) If you look at the sources for_XiCheckExtInit(), you'll see that it assumes that the display is *locked*, and, e.g, unlocks it on failure.
I must say I'm a bit confused at the fact that _XiCheckExtInit calls XGetExtensionVersion and vice-versa. The only calls to XGetExtensionVersion will be in _XiCheckExtInit(), and possibly in widget set/applications. Should XGetExtensionVersion lock the display by itself ?
Does the version in rawhide fix this issue?
*** Bug 115625 has been marked as a duplicate of this bug. ***
*** Bug 139690 has been marked as a duplicate of this bug. ***
*** Bug 308812 has been marked as a duplicate of this bug. ***