Bug 330991

Same bug, when trying to start wings3d (www.wings3d.org)

beam: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

export LIBXCB_ALLOW_SLOPPY_LOCK=1 fixed the problem..

Hm, I've discovered, that LIBXCB_ALLOW_SLOPPY_LOCK only helps in starting wings. But if I try to extrude a face or scale it (basic operations in 3d modeling), the app crashes with the following error:

> ./wings
Trying OpenGL modes
  [{buffer_size,32},{depth_size,32},{stencil_size,8},{accum_size,16}]
  [{buffer_size,24},{depth_size,32},{stencil_size,8},{accum_size,16}]
  [{buffer_size,24},{depth_size,24},{stencil_size,8},{accum_size,16}]
  [{buffer_size,24},{depth_size,24},{stencil_size,0},{accum_size,16}]
  [{buffer_size,16},{depth_size,24},{stencil_size,8},{accum_size,16}]
  [{buffer_size,16},{depth_size,16},{stencil_size,8},{accum_size,16}]
Actual: RGBA: 5 6 5 8 Depth: 16 Stencil: 8 Accum: 16 16 16 16
beam: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->reques                                       t)) >= 0)' failed.
Aborted
>

*** Bug 336158 has been marked as a duplicate of this bug. ***

*** Bug 329197 has been marked as a duplicate of this bug. ***

*** Bug 327532 has been marked as a duplicate of this bug. ***

The bug also prevents JBuilder (tested with JBuilder 2005 and 2007) to install and to work. 

Because I didn't know the variable LIBXCB_ALLOW_SLOPPY_LOCK, I used another workaround. I replaced the JRE and JDK 1.4.2_01 bundled with JBuilder 2005 and 2007 with the latest JRE 1.4.2 update (1.4.2_16). 

This bug also occurs with the java-gui "jbpSA" of Veritas NetBackup-6.0MP5 @ opensuse-10.3-x86_64:

% /usr/openv/netbackup/bin/jbpSA

        Starting user console version 6.0.
        The log file for this execution instance is
        /usr/openv/netbackup/logs/user_ops/nbjlogs/jbp.root.jbpSA.4913.log

/usr/openv/netbackup/bin/jbpSA: line 271:  4954 Aborted                 $JAVA_PATH -Dvrts.NBJAVA_CONF=$NBJ_CONF -showversion $HP64FLAG -Dvrts.common.server.LCCTYPE=${LCCTYPE} -Dvrts.common.server.LOG_CMDLINES=${LOG_CMDLINES} -Djava.library.path=${VRTS_LIBRARY_PATH} -Dvrts.common.utilities.DEBUG_PROPERTIES=$DEBUG_PROPERTIES -Dvrts.nbe.HOSTNAME=$LOGIN_HOST -Dvrts.nbe.INST_REL=$INSTALLED_RELEASE -Dvrts.nbe.BUILDNO=$BUILDNUMBER -Xms$INITIAL_MEMORY -Xmx$MAX_MEMORY vrts.nbe.UserConsole >> $LOG_FILE 2>&1

DISPLAY environment variable is set to: localhost:11.0
Console was started on:
        Linux heulsuse 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC x86_64 x86_64 x86_64 GNU/Linux

Command line options were:
        /usr/openv/netbackup/bin/jbpSA

Starting user console version 6.0.

LANG=POSIX
LC_CTYPE=de_DE.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

java version "1.4.2_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06)
Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode)

java: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

This is a very nasty bug ! It's referenced at Sun here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
The workaroud for OpenSuSE 10.3:
in a root terminal, first do:
$ find /usr -name 'libmawt*'>liblist ; cat liblist 
(you get a list of all affected libraries)
and then
$ for f in `cat liblist` ; do sed -i 's/XINERAMA/FAKEEXTN/g' $f ; done

It works !

It doesn't work for wings3d..

(In reply to comment #8 from Robert Cabane)
> $ find /usr -name 'libmawt*'>liblist ; cat liblist 
> (you get a list of all affected libraries)
> and then
> $ for f in `cat liblist` ; do sed -i 's/XINERAMA/FAKEEXTN/g' $f ; done

Don't work for NetBackup jbpSA. Perhaps because it brings its own
java runtime library with itself:

java version "1.4.2_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06)
Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode)

java: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

(but the LIBXCB_ALLOW_SLOPPY_LOCK workaround did work)

This is a duplicate of bug #252510, which is (falsely?) marked as fixed.  Suggest one of the reporters of this bug mark it as duplicate and reopen bug #252510 which will probably get more attention; I'd rather not do so myself as I can't currently reproduce this.

Same problem happens with Maple (MapleSoft) 11. 

This issue has been fixed for openSUSE 11.0. The assertion has been changed into a warning.

xorg-x11-libxcb.changes
-------------------------------------------------------------------
Mon Nov  5 14:58:18 CET 2007 - sndirsch@suse.de

- always-sloppy.diff
  * This patch prints out warnings only, the assert() is completely
    gone now. As programs with this error typically trigger it
    several times, each warning is printed only once. (Bug #251087)

(In reply to comment #13 from Stefan Dirsch)
> This issue has been fixed for openSUSE 11.0. The assertion has been changed
> into a warning.
> 
> xorg-x11-libxcb.changes
> -------------------------------------------------------------------
> Mon Nov  5 14:58:18 CET 2007 - sndirsch@suse.de
> 
> - always-sloppy.diff
>   * This patch prints out warnings only, the assert() is completely
>     gone now. As programs with this error typically trigger it
>     several times, each warning is printed only once. (Bug #251087)
> 

Hi Stephan will we not see a fix in openSUSE 10.3? Or will this just be a "Known" Blocker style bug (it's a blocker if people don't search the xlib.lock error)? 

Reason I ask is it cripples the Opera Browser (my preference) when trying to run Java Apps. 

Why blocker bug? The workaround is already mentioned in comment #1.

(In reply to comment #15 from Stefan Dirsch)
> Why blocker bug? The workaround is already mentioned in comment #1.
> 

Because every person I convert to openSUSE asks why this happens and I have to correct it. Seems silly since I think these functions should "just work" without a workaround, applying this fix to opensuse 10.3 would probably prevent quite a few emails on the mailing list and duplicated bug reports (or more importantly how about the many that don't research the problem and just try another distribution out?). 

I just think if the fix is created and it can be tested and marked stable on 10.3 it should be pushed out as a bug fix. 

Just a thought and my .02

So every person you convert to openSUSE installs Lotus Notes, which comes with it's own Java implementation (even already for installation)? All affected Java versions we ship include the workaround. The wings issue 

  beam: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) -  
                                                 (dpy->request)) >= 0)' failed.
  Aborted

should be handled in a seperate bugreport.

(In reply to comment #17 from Stefan Dirsch)
> So every person you convert to openSUSE installs Lotus Notes, which comes with
> it's own Java implementation (even already for installation)? All affected Java
> versions we ship include the workaround. The wings issue 
> 
>   beam: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) -  
>                                                  (dpy->request)) >= 0)' failed.
>   Aborted
> 
> should be handled in a seperate bugreport.
> 

The issue appears in Opera when trying to access some Java sites
The issue appears when installing Lotus Notes 8

Everyone in my enterprise uses Lotus Notes (I know SLED 10 works and we do have copies of that, but some people like openSUSE over SLED 10 (mostly admins etc)). 

> The issue appears in Opera when trying to access some Java sites
Strange. This shouldn't happen if Opera uses the installed Java version.

Which Java websites are this? I can't reproduce this issue.

(In reply to comment #20 from Stefan Dirsch)
> Which Java websites are this? I can't reproduce this issue.
> 

Stefan, 

Here is my output: 

bkevan@LSSUSE01007250:~> opera
Flash Player: Warning: environment variable G_FILENAME_ENCODING is set and is not UTF-8
Flash Player: Warning: environment variable G_FILENAME_ENCODING is set and is not UTF-8
Flash Player: Warning: environment variable G_FILENAME_ENCODING is set and is not UTF-8
opera: Plug-in 19813 is not responding. It will be closed.
opera: Define environment variable OPERA_KEEP_BLOCKED_PLUGIN to keep blocked plug-ins.
opera: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted


You can reproduce by launching opera. Going to: 
http://www.java.com/en/download/installed.jsp

Then click on "Verify Installation"

You will then get: 
opera: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted

And opera will close. 

That is one site off the top of my head I can verify the error. 

Thanks. After clicking "Verify Installation"

| Verifying Java Version 
|
|
| Oops! You don't have the recommended Java installed.
| Your Java version is 1.5.0_13. Please click the button below to get the 
| recommended Java for your computer.

Looks like you don't use the Java packages, which we ship with openSUSE 10.3.
And for these external packages the workaround has not been added of course.
I'm using opera-9.24-0.1 from openSUSE 10.3.

(In reply to comment #22 from Stefan Dirsch)
> Thanks. After clicking "Verify Installation"
> 
> | Verifying Java Version 
> |
> |
> | Oops! You don't have the recommended Java installed.
> | Your Java version is 1.5.0_13. Please click the button below to get the 
> | recommended Java for your computer.
> 
> Looks like you don't use the Java packages, which we ship with openSUSE 10.3.
> And for these external packages the workaround has not been added of course.
> I'm using opera-9.24-0.1 from openSUSE 10.3.
> 

? 

bkevan@LSSUSE01007250:~> rpm -qa | grep java
java-1_5_0-sun-plugin-1.5.0_update13-0.3
java-1_5_0-sun-1.5.0_update13-0.3
bkevan@LSSUSE01007250:~> rpm -qa | grep opera
opera-9.50-20071024.6
bkevan@LSSUSE01007250:~>

Those are the only Java Applications I run. Maybe your alternative sym links are broken due to the recent java update? Can you check in /etc/alternatives ? 

I am running Opera 9.50 Beta 1 now but the same issue was in 9.24 from the update repository. I actually moved to 9.50 to see if it would fix the issue. 

Ben

# rpm -qa|grep java
java-1_5_0-sun-1.5.0_update13-0.3
java-1_5_0-sun-plugin-1.5.0_update13-0.3

# rpm -qa|grep opera
opera-9.24-0.1

The links are *not* broken.

/etc/alternatives
-----------------
java -> /usr/lib/jvm/jre-1.5.0-sun/bin/java
java.1.gz -> /usr/share/man/man1/java-java-1_5_0-sun.1.gz
javaplugin -> /usr/lib/jvm/java-1.5.0-sun-1.5.0_update13/jre/plugin/i386/ns7/libjavaplugin_oji.so
javaws -> /usr/lib/jvm/jre-1.5.0-sun/bin/javaws
javaws.1.gz -> /usr/share/man/man1/javaws-java-1_5_0-sun.1.gz
jaxp_parser_impl -> /usr/share/java/xerces-j2.jar
jaxp_transform_impl -> /usr/share/java/xalan-j2.jar
jce_1.5.0_sun_local_policy -> /usr/lib/jvm-private/java-1_5_0-sun/jce/vanilla/local_policy.jar
jce_1.5.0_sun_us_export_policy -> /usr/lib/jvm-private/java-1_5_0-sun/jce/vanilla/US_export_policy.jar
jre -> /usr/lib/jvm/jre-1.5.0-sun
jre_1.5.0 -> /usr/lib/jvm/jre-1.5.0-sun
jre_1.5.0_exports -> /usr/lib/jvm-exports/jre-1.5.0-sun
jre_exports -> /usr/lib/jvm-exports/jre-1.5.0-sun
jre_sun -> /usr/lib/jvm/jre-1.5.0-sun
jre_sun_exports -> /usr/lib/jvm-exports/jre-1.5.0-sun

Maybe Java is builtin for opera in general and Java 1.6 is already part of your opera version? At least I get the same error message when uninstalling the java packages completely.

(In reply to comment #24 from Stefan Dirsch)
> # rpm -qa|grep java
> java-1_5_0-sun-1.5.0_update13-0.3
> java-1_5_0-sun-plugin-1.5.0_update13-0.3
> 
> # rpm -qa|grep opera
> opera-9.24-0.1
> 
> The links are *not* broken.
> 
> /etc/alternatives
> -----------------
> java -> /usr/lib/jvm/jre-1.5.0-sun/bin/java
> java.1.gz -> /usr/share/man/man1/java-java-1_5_0-sun.1.gz
> javaplugin ->
> /usr/lib/jvm/java-1.5.0-sun-1.5.0_update13/jre/plugin/i386/ns7/libjavaplugin_oji.so
> javaws -> /usr/lib/jvm/jre-1.5.0-sun/bin/javaws
> javaws.1.gz -> /usr/share/man/man1/javaws-java-1_5_0-sun.1.gz
> jaxp_parser_impl -> /usr/share/java/xerces-j2.jar
> jaxp_transform_impl -> /usr/share/java/xalan-j2.jar
> jce_1.5.0_sun_local_policy ->
> /usr/lib/jvm-private/java-1_5_0-sun/jce/vanilla/local_policy.jar
> jce_1.5.0_sun_us_export_policy ->
> /usr/lib/jvm-private/java-1_5_0-sun/jce/vanilla/US_export_policy.jar
> jre -> /usr/lib/jvm/jre-1.5.0-sun
> jre_1.5.0 -> /usr/lib/jvm/jre-1.5.0-sun
> jre_1.5.0_exports -> /usr/lib/jvm-exports/jre-1.5.0-sun
> jre_exports -> /usr/lib/jvm-exports/jre-1.5.0-sun
> jre_sun -> /usr/lib/jvm/jre-1.5.0-sun
> jre_sun_exports -> /usr/lib/jvm-exports/jre-1.5.0-sun
> 
> Maybe Java is builtin for opera in general and Java 1.6 is already part of your
> opera version? At least I get the same error message when uninstalling the java
> packages completely.
> 

Very strange. So it seems as though Opera isn't even seeing my Java as being installed and is using some type of "Bundled Java"? Is that what you are implying? 

If I do the sloppy lock work around and run opera it indeed works. 

I am glad you can at least duplicate the issue it is quite puzzling to me. 

Ben

I was wrong. opera uses libjvm.so, libawt.so and libjava.so of java-1.5.0-sun package. The problem is that it uses the libs and not the java VM, which has been turned into a shellscript wrapper to add the sloppy lock workaround.

*** Bug 352275 has been marked as a duplicate of this bug. ***