After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 111349 - libXi with XInitThreads is broken
libXi with XInitThreads is broken
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other other
: Normal blocker
: ---
Assigned To: gtk-bugs
GStreamer Maintainers
: 111880 115625 139690 308812 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-04-22 13:36 UTC by Bastien Nocera
Modified: 2005-06-24 06:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
locks debugging with debug X libraries (4.38 KB, text/plain)
2003-04-27 19:36 UTC, Bastien Nocera
  Details
patch for XFree86 4.3.0 (500 bytes, patch)
2003-04-30 13:53 UTC, Bastien Nocera
none Details | Review

Description Bastien Nocera 2003-04-22 13:36:44 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:

  • #0 ??
  • #1 _XUnregisterFilter
    from /usr/X11R6/lib/libX11.so.6
  • #2 XGetExtensionVersion
    from /usr/X11R6/lib/libXi.so.6
  • #3 _XiCheckExtInit
    from /usr/X11R6/lib/libXi.so.6
  • #4 XListInputDevices
    from /usr/X11R6/lib/libXi.so.6
  • #5 _gdk_input_common_init
    from /usr/lib/libgdk-x11-2.0.so.0
  • #6 _gdk_input_init
    from /usr/lib/libgdk-x11-2.0.so.0
  • #7 gdk_display_open
    from /usr/lib/libgdk-x11-2.0.so.0
  • #8 gdk_display_open_default_libgtk_only
    from /usr/lib/libgdk-x11-2.0.so.0
  • #9 gtk_init_check
    from /usr/lib/libgtk-x11-2.0.so.0
  • #10 gtk_init
    from /usr/lib/libgtk-x11-2.0.so.0
  • #11 main
  • #12 __libc_start_main
    from /lib/tls/libc.so.6
  • #0 __pthread_sigsuspend
    from /lib/libpthread.so.0
  • #1 __pthread_wait_for_restart_signal
    from /lib/libpthread.so.0
  • #2 __pthread_alt_lock
    from /lib/libpthread.so.0
  • #3 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #4 _XUnregisterFilter
    from /usr/X11R6/lib/libX11.so.6
  • #5 XGetExtensionVersion
    from /usr/X11R6/lib/libXi.so.6
  • #6 _XiCheckExtInit
    from /usr/X11R6/lib/libXi.so.6
  • #7 XListInputDevices
    from /usr/X11R6/lib/libXi.so.6
  • #8 _gdk_input_common_init
    from /usr/lib/libgdk-x11-2.0.so.0
  • #9 _gdk_input_init
    from /usr/lib/libgdk-x11-2.0.so.0
  • #10 gdk_display_open
    from /usr/lib/libgdk-x11-2.0.so.0
  • #11 gdk_display_open_default_libgtk_only
    from /usr/lib/libgdk-x11-2.0.so.0
  • #12 gtk_init_check
    from /usr/lib/libgtk-x11-2.0.so.0
  • #13 gtk_init
    from /usr/lib/libgtk-x11-2.0.so.0
  • #14 main
  • #15 __libc_start_main
    from /lib/libc.so.6

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.
Comment 1 Bastien Nocera 2003-04-22 13:42:28 UTC
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.
Comment 2 Bastien Nocera 2003-04-22 14:31:35 UTC
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.
Comment 3 Owen Taylor 2003-04-22 16:38:54 UTC
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.)
Comment 4 Julien MOUTTE 2003-04-26 18:27:51 UTC
Here is the backtrace with debugging infos...

Hope this helps..

gtk+-2.0 version 2.2.1
Xfree 4.3

(gdb) bt
  • #0 sigsuspend
    from /lib/libc.so.6
  • #1 __pthread_wait_for_restart_signal
    from /lib/libpthread.so.0
  • #2 __pthread_alt_lock
    from /lib/libpthread.so.0
  • #3 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #4 _XLockDisplay
    at locking.c line 478
  • #5 XGetExtensionVersion
    at XGetVers.c line 108
  • #6 _XiCheckExtInit
    at XExtInt.c line 198
  • #7 XListInputDevices
    at XListDev.c line 85
  • #8 _gdk_input_common_init
    from /usr/lib/libgdk-x11-2.0.so.0
  • #9 _gdk_input_init
    from /usr/lib/libgdk-x11-2.0.so.0
  • #10 gdk_display_open
    from /usr/lib/libgdk-x11-2.0.so.0
  • #11 gdk_display_open_default_libgtk_only
    from /usr/lib/libgdk-x11-2.0.so.0
  • #12 gtk_init_check
    from /usr/lib/libgtk-x11-2.0.so.0
  • #13 gtk_init
    from /usr/lib/libgtk-x11-2.0.so.0
  • #14 bonobo_dock_layout_parse_string
    from /usr/lib/libbonoboui-2.so.0
  • #15 gnome_program_postinit
    from /usr/lib/libgnome-2.so.0
  • #16 gnome_program_initv
    from /usr/lib/libgnome-2.so.0
  • #17 gnome_program_init
    from /usr/lib/libgnome-2.so.0
  • #18 main
    at totem.c line 3131
  • #19 __libc_start_main
    from /lib/libc.so.6

Comment 5 Owen Taylor 2003-04-26 19:09:02 UTC
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.
Comment 6 Bastien Nocera 2003-04-27 19:36:22 UTC
Created attachment 16062 [details]
locks debugging with debug X libraries
Comment 7 Bastien Nocera 2003-04-27 19:38:36 UTC
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?
Comment 8 Bastien Nocera 2003-04-27 19:54:46 UTC
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.
Comment 9 Bastien Nocera 2003-04-29 20:30:26 UTC
Sorry for the spam
Comment 10 Bastien Nocera 2003-04-29 23:07:43 UTC
*** Bug 111880 has been marked as a duplicate of this bug. ***
Comment 11 Bastien Nocera 2003-04-30 13:53:14 UTC
Created attachment 16145 [details] [review]
patch for XFree86 4.3.0
Comment 12 Bastien Nocera 2003-04-30 13:54:25 UTC
Close the bug. Point your XFree86 maintainer to this bug for a fix. It
has already been sent to Red Hat, Debian and Mandrake.
Comment 13 Owen Taylor 2003-04-30 14:12:55 UTC
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.
 
Comment 14 Bastien Nocera 2003-04-30 14:55:36 UTC
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 ?
Comment 15 louisg00 2003-05-03 20:14:33 UTC
Does the version in rawhide fix this issue?
Comment 16 Bastien Nocera 2003-06-20 20:04:40 UTC
*** Bug 115625 has been marked as a duplicate of this bug. ***
Comment 17 Bastien Nocera 2004-04-12 18:38:35 UTC
*** Bug 139690 has been marked as a duplicate of this bug. ***
Comment 18 Bastien Nocera 2005-06-24 06:58:28 UTC
*** Bug 308812 has been marked as a duplicate of this bug. ***