XCB failed assertion on linux

[matrixhax0r]

Hi, I've got my X11 and Mesa compiled with XCB and I get "java: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed." when I try to run examples.

Read more about it here: http://lwn.net/Articles/211808/
Specifically:

..these represent bugs in a caller of libX11, and *not* in libX11 or libxcb. [It] means that a caller attempted to lock the display while already locked.

I'm not sure if this is a sun-java issue or because of the lwjgl, but I don't seem to be running into problems on my other apps.

[Matzon]

It is likely that it is lwjgl code, but we cant rule out the jre either.
Do these assertion errors cause the application to stop running, or is it simply a warning ?

[matrixhax0r]

The error causes the application to stop working and it doesn't appear to throw an exception.

I ran some of the examples through debug on eclipse, and the error seems to happen in the first JNI call. For example:
Display.getAdapter() for org.lwjgl.test.DisplayTest or
Display.setTitle() for org.lwjgl.examples.Game
There's a slight pause as the libraries are loaded and then the application quits.

[elias]

First, I'd really like to get lwjgl working with xcb, but I'm not sure I understand the problem completely. If the problem is calling XLockDisplay multiple times from the same thread (nested usage), I don't see why this is not allowed:

Nested calls to XLockDisplay() work correctly; the display will not actually be unlocked until XUnlockDisplay() has been called the same number of times as XLockDisplay()

(from http://tronche.com/gui/x/xlib/display/XLockDisplay.html)

Secondly, LWJGL never calls XLockDisplay directly, but I suspect it is called through the AWT Lock JNI primitive, which is used by LWJGL. So this could possibly be a bug in the sun implementation.

- elias

[elias]

The error causes the application to stop working and it doesn't appear to throw an exception.

I ran some of the examples through debug on eclipse, and the error seems to happen in the first JNI call. For example:
Display.getAdapter() for org.lwjgl.test.DisplayTest or
Display.setTitle() for org.lwjgl.examples.Game
There's a slight pause as the libraries are loaded and then the application quits.

This is odd - Display.getAdapter() is not implemented on linux (always returns null) and Display.setTitle doesn't do any JNI unless the Display has been created. Are you sure the program crashes at those calls?

Secondly, have you tried running any "pure" AWT program without using LWJGL on the new xlib? If the crash still happens, it's definitely a Sun problem and should be reported to them ASAP (Sun has a long turn around for fixes, and XCB could be widespread in half a year or so).

- elias

[elias]

I managed to trigger the assertion here on my own machine with a parallel install of XCB and the Xlib wrapper. However, it seems that the bug is really caused by the Xrandr library or a library Xrandr depends on. Here's a simple C program that also fails using XCB:

#include <X11/X.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/extensions/Xrandr.h>

int main() {
    Display *disp = XOpenDisplay(NULL);
    int num_sizes;
    XRRSizes(disp, 0, &num_sizes);
}

gdb gives me this:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d40770 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d41ef3 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7d39dbb in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7d15834 in xcb_xlib_lock (c=0x804a7f8) at xcb_xlib.c:41
#5  0xb7e99a8c in _XCBLockDisplay (dpy=0x804a008) at xcb_lock.c:20
#6  0xb7e886b6 in XQueryExtension (dpy=0x804a008, name=0xb7e59188 "RANDR", major_opcode=0xbfbfb2c0, first_event=0xbfbfb2c4, first_error=0xbfbfb2c8)
    at QuExt.c:46
#7  0xb7e7d49b in XInitExtension (dpy=0x804a008, name=0xb7e59188 "RANDR") at InitExt.c:49
#8  0xb7cf8073 in XextAddDisplay (extinfo=0xb7e591d0, dpy=0x804a008, ext_name=0xb7e59188 "RANDR", hooks=0xb7e591a0, nevents=1, data=0x0) at extutil.c:108
#9  0xb7e57f3a in XRRFindDisplay (dpy=0x804a008) at Xrandr.c:139
#10 0xb7e58a87 in _XRRValidateCache (dpy=0x0, screen=6) at Xrandr.c:242
#11 0xb7e58bf7 in XRRSizes (dpy=0x804a008, screen=0, nsizes=0xbfbfb39c) at Xrandr.c:284
#12 0x080484ae in main ()
(

- elias

[matrixhax0r]

Yep, that simple program breaks on my system too 
Well, this means I get lots of time to work on my code while waiting for upstream to get ready.

[elias]

Ok, I've reported the issue to the xcb mailing list in hope that they'll know about a fix (or tell me it is already fixed in a development version).

- elias

[matrixhax0r]

http://lists.freedesktop.org/archives/xcb/2007-January/thread.html#2513
Oh thanks for helping out.

"In this case, as you mentioned in a later mail, libXrandr makes the problematic call."

Also,
"What version of the X11 server and libraries is the user using?"

[ebuild   R   ] x11-proto/compositeproto-0.3.1 
[ebuild   R   ] x11-proto/damageproto-1.0.3 
[ebuild   R   ] x11-libs/libX11-1.1.1 
[ebuild   R   ] x11-libs/libXau-1.0.3 
[ebuild   R   ] x11-libs/libxcb-1.0 
[ebuild   R   ] x11-libs/libXcomposite-0.3.1 
[ebuild   R   ] x11-libs/libXcursor-1.1.8 
[ebuild   R   ] x11-libs/libXdamage-1.0.4 
[ebuild   R   ] x11-libs/libXdmcp-1.0.2 
[ebuild   R   ] x11-libs/libXext-1.0.2 
[ebuild   R   ] x11-libs/libXfixes-4.0.3 
[ebuild   R   ] x11-libs/libXp-1.0.0 
[ebuild   R   ] x11-libs/libXrandr-1.1.2 
[ebuild   R   ] x11-libs/libXrender-0.9.2 
[ebuild   R   ] x11-libs/libXtst-1.0.1 
[ebuild   R   ] x11-libs/libXxf86misc-1.0.1 
[ebuild   R   ] x11-proto/printproto-1.0.3 
[ebuild   R   ] x11-proto/recordproto-1.13.2 
[ebuild   R   ] x11-proto/xcb-proto-1.0 
[ebuild   R   ] x11-libs/xcb-util-0.1_p20061216

I'm basically running X.Org 7.1 with the xcb support

[elias]

It seems that the program is fixed upstream now.

- elias