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:
int main (int argc, char **argv)
if (XInitThreads() == 0)
g_message ("XInitThreads() = 0");
gtk_init (&argc, &argv);
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
launch ./test, and see it hang... Here's the backtrace from it:
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/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
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
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:
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. ***