Summary: | Yet another assertion in xcb_xlib_lock | ||
---|---|---|---|
Product: | xorg | Reporter: | Magnus Kessler <Magnus.Kessler> |
Component: | Lib/Xlib | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED NOTOURBUG | QA Contact: | |
Severity: | normal | ||
Priority: | high | CC: | biebl |
Version: | 7.2 (2007.02) | ||
Hardware: | Other | ||
OS: | other | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Magnus Kessler
2006-11-08 13:11:12 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 () 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? |
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.