LWJGL
April 19, 2014, 20:34:55 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: LWJGL is now using GitHub
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: XCB failed assertion on linux  (Read 11441 times)
matrixhax0r
Newbie
*
Posts: 4


« on: December 30, 2006, 17:35:20 »

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:
Quote
..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.
Logged
Matzon
Administrator
Demigod
*****
Posts: 2242



« Reply #1 on: December 31, 2006, 01:43:02 »

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 ?
Logged

matrixhax0r
Newbie
*
Posts: 4


« Reply #2 on: December 31, 2006, 10:56:47 »

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.
Logged
elias
Nerdus Imperius
*****
Posts: 899



WWW
« Reply #3 on: January 02, 2007, 01:59:27 »

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:

Quote
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
Logged

elias
Nerdus Imperius
*****
Posts: 899



WWW
« Reply #4 on: January 02, 2007, 02:04:10 »

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
Logged

elias
Nerdus Imperius
*****
Posts: 899



WWW
« Reply #5 on: January 03, 2007, 15:44:42 »

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:

Code:
#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:

Code:
#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
Logged

matrixhax0r
Newbie
*
Posts: 4


« Reply #6 on: January 03, 2007, 18:21:12 »

Yep, that simple program breaks on my system too  Undecided
Well, this means I get lots of time to work on my code while waiting for upstream to get ready.
Logged
elias
Nerdus Imperius
*****
Posts: 899



WWW
« Reply #7 on: January 04, 2007, 00:01:12 »

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
Logged

matrixhax0r
Newbie
*
Posts: 4


« Reply #8 on: January 04, 2007, 16:01:48 »

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?"
Quote
[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
Logged
elias
Nerdus Imperius
*****
Posts: 899



WWW
« Reply #9 on: January 06, 2007, 23:47:42 »

It seems that the program is fixed upstream now.

 - elias
Logged

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines
SMFAds for Free Forums
Valid XHTML 1.0! Valid CSS!