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 413032 - Locking issue with xcb in IA__gdk_display_sync
Locking issue with xcb in IA__gdk_display_sync
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other Linux
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-02-28 12:42 UTC by Sebastian Dröge (slomo)
Modified: 2007-03-09 05:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2007-02-28 12:42:27 UTC
Hi,
with latest gtk 2.10.9 and xcb 1.0 several gtk applications fail with a assertion in XCB's locking code:

xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.


Below I'll attach backtraces for xchat and epiphany showing this behaviour. All were produced by having a Gtk window unfocused and dragging some window from the wnck window applet to this window a few times.

nautilus and other's can be crashed the same way.

It wasn't always the application that was dragged or to which was dragged that crashed.

Bye
Comment 1 Sebastian Dröge (slomo) 2007-02-28 12:43:12 UTC
xchat:


Comment 2 Sebastian Dröge (slomo) 2007-02-28 12:44:06 UTC
epiphany (Thread 1 crashed running the Gtk main loop... for both backtraces):


Thread 1 (process 9902)

  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libc.so.6
  • #2 nsProfileLock::FatalSignalHandler
    at nsProfileLock.cpp line 206
  • #3 <signal handler called>
  • #4 __kernel_vsyscall
  • #5 raise
    from /lib/tls/i686/cmov/libc.so.6
  • #6 abort
    from /lib/tls/i686/cmov/libc.so.6
  • #7 __assert_fail
    from /lib/tls/i686/cmov/libc.so.6
  • #8 xcb_xlib_lock
    from /usr/lib/libxcb-xlib.so.0
  • #9 _XCBLockDisplay
    at ../../src/xcb_lock.c line 20
  • #10 XSync
    at ../../src/Sync.c line 46
  • #11 IA__gdk_display_sync
    at gdkdisplay-x11.c line 635
  • #12 xdnd_manage_source_filter
    at gdkdnd-x11.c line 2595
  • #13 gdk_drag_context_finalize
    at gdkdnd-x11.c line 184
  • #14 IA__g_object_unref
    at gobject.c line 1788
  • #15 send_client_message_async_cb
    at gdkdnd-x11.c line 2157
  • #16 send_event_handler
    at gdkasync.c line 150
  • #17 process_responses
    at ../../src/xcb_io.c line 98
  • #18 _XEventsQueued
    at ../../src/xcb_io.c line 196
  • #19 XPending
    at ../../src/Pending.c line 57
  • #20 gdk_check_xpending
    at gdkevents-x11.c line 148
  • #21 gdk_event_check
    at gdkevents-x11.c line 2292
  • #22 IA__g_main_context_check
    at gmain.c line 2552
  • #23 g_main_context_iterate
    at gmain.c line 2674
  • #24 IA__g_main_loop_run
    at gmain.c line 2881
  • #25 IA__gtk_main
    at gtkmain.c line 1171
  • #26 main

Comment 3 Sebastian Dröge (slomo) 2007-02-28 12:48:18 UTC
Might be related to bug #353842 though this was with normal libX11... probably a deadlock while xcb just asserts for this.
Comment 4 Sebastian Dröge (slomo) 2007-02-28 16:23:24 UTC
Also crashes gnome-panel under some situations, backtrace is different there though and one gets a segfault and no xcb assertions... but at the same time most of the time other apps, like xchat or epiphany for example, crash with the xcb assertion pasted above. Below is the gnome-panel backtrace:

Thread 1 (process 7953)

  • #0 set_icon_stock_pixbuf
    at gtkdnd.c line 3008
  • #1 IA__gtk_drag_set_icon_default
    at gtkdnd.c line 3204
  • #2 wnck_drag_window_destroyed
    at pager.c line 1472
  • #3 weak_refs_notify
    at gobject.c line 1461
  • #4 IA__g_datalist_id_set_data_full
    at gdataset.c line 242
  • #5 g_object_real_dispose
    at gobject.c line 534
  • #6 IA__g_object_unref
    at gobject.c line 1760
  • #7 _wnck_window_destroy
    at window.c line 443
  • #8 do_update_now
    at screen.c line 1414
  • #9 update_idle
    at screen.c line 1936
  • #10 g_idle_dispatch
    at gmain.c line 3928
  • #11 IA__g_main_context_dispatch
    at gmain.c line 2045
  • #12 g_main_context_iterate
    at gmain.c line 2677
  • #13 IA__g_main_loop_run
    at gmain.c line 2881
  • #14 IA__gtk_main
    at gtkmain.c line 1171
  • #15 main

Comment 5 Chris Rose 2007-02-28 17:37:37 UTC
I can reproduce this also, if any other backtraces are needed.

Ubuntu bug: https://launchpad.net/ubuntu/+source/gtk+2.0/+bug/88608
Comment 6 Sebastian Dröge (slomo) 2007-02-28 18:32:17 UTC
And also happens completely unmotivated, without moving the cursor or typing something. Just happend to me with epiphany...
Comment 7 Matthias Clasen 2007-03-08 22:27:04 UTC
This turns out to be an incompatibility between traditional and xcb-ified
xlib wrt to some semi-internal apis. Old libX11 executed the async callbacks 
outside of the display lock, xcb does it inside the lock. Thus the we deadlock
as soon as the callback calls back into libX11.

Possible fixes:

- rewrite gdkasync.c to use xcb directly, rather than rely on the xcb-emulation
  of internal Xlib apis. This is quite a bit of work, and probably best undertaken
  in the context of an xcb backend for GDK.

- defer the callbacks to an idle.
Comment 8 Matthias Clasen 2007-03-09 05:33:09 UTC
2007-03-08  Matthias Clasen <mclasen@redhat.com>

        * gdk/x11/gdkasync.c (send_event_handler): Defer the callbacks
        to an idle to avoid deadlock with xcb-ified libX11.  (#413032,
        Sebastian Dröge)