Bug 8947 - Yet another assertion in xcb_xlib_lock
Summary: Yet another assertion in xcb_xlib_lock
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (show other bugs)
Version: 7.2 (2007.02)
Hardware: Other other
: high normal
Assignee: Xorg Project Team
QA Contact:
: 9248 (view as bug list)
Depends on:
Reported: 2006-11-08 13:11 UTC by Magnus Kessler
Modified: 2006-12-04 20:51 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Magnus Kessler 2006-11-08 13:11:12 UTC
Here's another locking assertion that is caused by not unlocking the display 
before calling a user defined callback function.

#13 0xb6f93119 in *__GI_raise (sig=6) at raise.c:64
#14 0xb6f94543 in *__GI_abort () at abort.c:88
#15 0xb6f8ccbd in *__GI___assert_fail (assertion=0xb71aa88f "!c->xlib.lock", 
    file=0xb71aa884 "xcb_xlib.c", line=41, 
    function=0xb71aa8de "xcb_xlib_lock") at assert.c:78
#16 0xb71aa834 in xcb_xlib_lock (c=0x80553a0) at xcb_xlib.c:41
#17 0xb71eaa13 in _XCBLockDisplay (dpy=0x8054c18) at xcb_lock.c:20
#18 0xb71c8923 in XFreeCursor (dpy=0x8054c18, cursor=18874987)
    at FreeCurs.c:40
#19 0xb754313e in ~QCursorData (this=0x8054bd0) at qcursor_x11.cpp:87
#20 0xb754328f in ~QCursor (this=0x710a) at qcursor_x11.cpp:279
#21 0xb75432c3 in __tcf_0 () at qcursor_x11.cpp:101
#22 0xb6f95b1c in __cxa_finalize (d=0xb7a2c520) at cxa_finalize.c:48
#23 0xb752ac2b in __do_global_dtors_aux () from /usr/qt/3/lib/libqt-mt.so.3
#24 0xb79370f0 in _fini () from /usr/qt/3/lib/libqt-mt.so.3
#25 0xb7feac97 in _dl_fini () at dl-fini.c:248
#26 0xb6f95876 in *__GI_exit (status=1) at exit.c:75
#27 0xb752c748 in qt_xio_errhandler () at qapplication_x11.cpp:731
#28 0xb7b4281a in KApplication::xioErrhandler (this=0xbfafc360, dpy=0x8054c18)
    at kapplication.cpp:728
#29 0xb7b42855 in kde_xio_errhandler (dpy=0x8054c18) at kapplication.cpp:179
#30 0xb71e4449 in _XIOError (dpy=0x6) at XlibInt.c:2930
#31 0xb71eb301 in process_responses (dpy=0x8054c18, 
    wait_for_first_event=<value optimized out>, current_error=0x0, 
    current_request=8706) at xcb_io.c:152
#32 0xb71eb7f9 in _XEventsQueued (dpy=0x8054c18, mode=2) at xcb_io.c:166
#33 0xb71d5dd4 in XPending (dpy=0x8054c18) at Pending.c:57
#34 0xb754a2b5 in QEventLoop::processEvents (this=0x8078ab0, flags=4)
    at qeventloop_x11.cpp:147
#35 0xb75ac92d in QEventLoop::enterLoop (this=0x8078ab0) at qeventloop.cpp:198
#36 0xb75ac7d2 in QEventLoop::exec (this=0x8078ab0) at qeventloop.cpp:145
#37 0xb7596bad in QApplication::exec (this=0xbfafc360)
    at qapplication.cpp:2758
#38 0xb7f99e93 in kdemain (argc=3, argv=0xbfafc5d4) at main.cpp:285
#39 0x080486db in main (argc=) at kwin.la.cpp:2
#40 0xb6f80864 in __libc_start_main (main=0x80486bc <main>, argc=3, 
    ubp_av=0xbfafc5d4, init=0x80486e9 <__libc_csu_init>, 
    fini=0x80486e4 <__libc_csu_fini>, rtld_fini=0xb7feaa63 <_dl_fini>, 
    stack_end=0xbfafc5cc) at libc-start.c:238
#41 0x0804863d in _start ()

I believe (same reasoning as in bug 8582) that in _XIOError the display lock 
should be released before the callback in XlibInt.c:2930 and re-obtained 

diff --git a/src/XlibInt.c b/src/XlibInt.c
index a6166f2..8f6f67f 100644
--- a/src/XlibInt.c
+++ b/src/XlibInt.c
@@ -2926,10 +2926,14 @@ #ifdef WIN32
     errno = WSAGetLastError();

-    if (_XIOErrorFunction != NULL)
+    if (_XIOErrorFunction != NULL) {
+       /* callback without lock */
+       UnlockDisplay(dpy);
-    else
+       LockDisplay(dpy);
+    } else {
+    }
     exit (1);
     return 0;
Comment 1 Magnus Kessler 2006-11-08 14:28:01 UTC
Sorry, the patch above does not work. With it applied I get

#13 0xb6f4c119 in *__GI_raise (sig=6) at raise.c:64
#14 0xb6f4d543 in *__GI_abort () at abort.c:88
#15 0xb6f45cbd in *__GI___assert_fail (
    assertion=0xb720a424 "xcb_get_request_sent(dpy->xcb->connection) == 
dpy->request", file=0xb720a2e0 "xcb_lock.c", line=28, 
    function=0xb720a4a3 "_XCBUnlockDisplay") at assert.c:78
#16 0xb71a39fd in _XCBUnlockDisplay (dpy=0x8054c18) at xcb_lock.c:28
#17 0xb719d456 in _XIOError (dpy=0x8054c18) at XlibInt.c:2931
#18 0xb71a4321 in process_responses (dpy=0x8054c18, 
    wait_for_first_event=<value optimized out>, current_error=0x0, 
    current_request=4571) at xcb_io.c:152
#19 0xb71a4819 in _XEventsQueued (dpy=0x8054c18, mode=2) at xcb_io.c:166
#20 0xb718edd4 in XPending (dpy=0x8054c18) at Pending.c:57
#21 0xb75032b5 in QEventLoop::processEvents (this=0x8078af8, flags=4)
    at qeventloop_x11.cpp:147
#22 0xb756592d in QEventLoop::enterLoop (this=0x8078af8) at qeventloop.cpp:198
#23 0xb75657d2 in QEventLoop::exec (this=0x8078af8) at qeventloop.cpp:145
#24 0xb754fbad in QApplication::exec (this=0xbfb8cbf0)
    at qapplication.cpp:2758
#25 0xb7f52e93 in kdemain (argc=3, argv=0xbfb8ce64) at main.cpp:285
#26 0x080486db in main (argc=) at kwin.la.cpp:2
#27 0xb6f39864 in __libc_start_main (main=0x80486bc <main>, argc=3, 
    ubp_av=0xbfb8ce64, init=0x80486e9 <__libc_csu_init>, 
    fini=0x80486e4 <__libc_csu_fini>, rtld_fini=0xb7fa3a63 <_dl_fini>, 
    stack_end=0xbfb8ce5c) at libc-start.c:238
#28 0x0804863d in _start ()
Comment 2 Jamey Sharp 2006-11-15 14:38:44 UTC
Uh... That's broken behavior on Qt's part. When _XIOError is called, the Display
is in an undefined state: the only thing the callback is allowed to do is die.
The XFreeCursor call it's trying to make is guaranteed to fail anyway.

I think having the application assert-fail in this case is pretty reasonable,
don't you?
Comment 3 Jamey Sharp 2006-12-04 20:51:41 UTC
*** Bug 9248 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.