Ubuntu
sun-java5 package

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

Bug #86103 reported by Leon van der Ree
364
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Sun Java
Fix Released
Unknown
xlibs
Won't Fix
Critical
icedtea-java7 (Ubuntu)
Invalid
Undecided
Unassigned
jabref (Ubuntu)
Invalid
Undecided
Unassigned
sun-java5 (Debian)
Fix Released
Unknown
sun-java5 (Ubuntu)
Fix Released
High
Unassigned
sun-java6 (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Azureus crashes with both sun-java5 and sun-java6

This error came from azureus and sun-java5, when it started a download:

Starting Azureus...
Java exec found in PATH. Verifying...
Suitable java version found [java = 1.5.0_11]
Configuring environment...
Loading Azureus:
java -Xms16m -Xmx128m -cp "/opt/azureus/Azureus2.jar:/opt/azureus/swt.jar" -Djava.library.path="/opt/azureus" -Dazureus.install.path="/opt/azureus" org.gudy.azureus2.ui.swt.Main ''

java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
./azureus: line 112: 32551 Aborted (core dumped) ${JAVA_PROGRAM_DIR}java -Xms16m -Xmx128m -cp "${CLASSPATH}" -Djava.library.path="${PROGRAM_DIR}" -Dazureus.install.path="${PROGRAM_DIR}" org.gudy.azureus2.ui.swt.Main "$@"
Azureus TERMINATED.

And with sun-java6 again:

./azureus: line 112: 20574 Aborted (core dumped) ${JAVA_PROGRAM_DIR}java -Xms16m -Xmx128m -cp "${CLASSPATH}" -Djava.library.path="${PROGRAM_DIR}" -Dazureus.install.path="${PROGRAM_DIR}" org.gudy.azureus2.ui.swt.Main "$@"
Azureus TERMINATED.

with java-gcj everything works out OK

Tags: metabug
Matthias Klose (doko)
Changed in sun-java5:
status: Unconfirmed → Confirmed
Matthias Klose (doko)
Changed in sun-java5:
importance: Undecided → High
Revision history for this message
Amadeus Foudray (afoudray) wrote :

Duplicated with every Java GUI program I have installed. I've included the hs_err* stack trace from trying to start the Java console.

Stack: [0xb7dbe000,0xb7e0f000), sp=0xb7e0ce60, free space=315k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.6+0x2b761] abort+0x221
C [libc.so.6+0x2343b] __assert_fail+0xfb
C [libxcb-xlib.so.0+0x651] xcb_xlib_unlock+0x81
C [libX11.so.6+0x43962] _XReply+0xd2
C [libmawt.so+0xb028e]
C [libmawt.so+0x54b77]
C [libmawt.so+0x54e28]
C [libmawt.so+0x5512f] Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f
j sun.awt.X11GraphicsEnvironment.initDisplay(Z)V+0
j sun.awt.X11GraphicsEnvironment.access$100(Z)V+1
j sun.awt.X11GraphicsEnvironment$1.run()Ljava/lang/Object;+72
v ~StubRoutines::call_stub
V [libjvm.so+0x2b521d]
V [libjvm.so+0x43d9a8]
V [libjvm.so+0x2b50b0]
V [libjvm.so+0x30af2b]
C [libjava.so+0xa96d] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0
j sun.awt.X11GraphicsEnvironment.<clinit>()V+54
v ~StubRoutines::call_stub
V [libjvm.so+0x2b521d]
V [libjvm.so+0x43d9a8]
V [libjvm.so+0x2b50b0]
V [libjvm.so+0x28ef96]
V [libjvm.so+0x28dcc0]
V [libjvm.so+0x28d008]
V [libjvm.so+0x31ecfd]
V [libjvm.so+0x3088d1]
C [libjava.so+0xb246] Java_java_lang_Class_forName0+0x116
j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+0
j java.lang.Class.forName(Ljava/lang/String;)Ljava/lang/Class;+5
j sun.swing.SwingUtilities2.isLocalDisplay()Z+17
j javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(Ljavax/swing/UIDefaults;)V+12212
j javax.swing.plaf.basic.BasicLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+25
j javax.swing.plaf.metal.MetalLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+9
j javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+79
j javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+16
j javax.swing.UIManager.initializeDefaultLAF(Ljava/util/Properties;)V+28
j javax.swing.UIManager.initialize()V+9
j javax.swing.UIManager.maybeInitialize()V+22
j javax.swing.UIManager.getLookAndFeel()Ljavax/swing/LookAndFeel;+0
j sun.tools.jconsole.JConsole.updateLafValues()V+0
j sun.tools.jconsole.JConsole.<clinit>()V+62
v ~StubRoutines::call_stub
V [libjvm.so+0x2b521d]
V [libjvm.so+0x43d9a8]
V [libjvm.so+0x2b50b0]
V [libjvm.so+0x28ef96]
V [libjvm.so+0x28dcc0]
V [libjvm.so+0x28d008]
V [libjvm.so+0x31ecfd]
V [libjvm.so+0x2bbf5a]
C [jconsole+0x3487]
C [jconsole+0x1c0f] JavaMain+0x3df
C [libpthread.so.0+0x531b]

Bug Watch Updater (bug-watch-updater)
Changed in sun-java5:
status: Unknown → Unconfirmed
Bug Watch Updater (bug-watch-updater)
Changed in sun-java:
status: Unknown → Confirmed
Revision history for this message
Trent Lloyd (lathiat) wrote :

Confirmed here with azureus & some in browser applets.

Revision history for this message
Henri Cook (henricook) wrote :

Confirmed here (Feisty Latest, Java6) - effectively halting any development work I *might* have been doing on this system.

Revision history for this message
Henri Cook (henricook) wrote :

Confirmed with Java6 in Eclipse SDK

Changed in sun-java6:
status: Unconfirmed → Confirmed
Revision history for this message
Michael (m-gruys) wrote :

Confirmed with any JAVA version running JAVA applets with firefox / epeihany
e.g. firefox http://www.forexdirectory.net/euro.html
causes crash of browser

Revision history for this message
Frank Louwers (frank-openminds) wrote :

Confirmed in sun-java6 as well :(

Revision history for this message
Lorenco Trichardt (trichalo) wrote :

Confirmed with Any Java Version I Tried.Any application on my system:
Tried all :
Selection Alternative
-----------------------------------------------
          1 /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
 + 2 /usr/lib/j2re1.5-ibm/jre/bin/java
          3 /usr/lib/j2sdk1.5-ibm/bin/java
* 4 /usr/lib/jvm/java-6-sun/jre/bin/java
          5 /usr/bin/gij-wrapper-4.1

bummer ....
I have Java dumps .... but looks like it should be easily replicated

Using latest Feisty release....

Revision history for this message
flim (post-flim) wrote :

I too encounter the above problems. There's not much material available online, but the problem seems to be bound to the version of xlib/x11 in feisty (though it might not be a bug in xlib). I'd consider this to be of really high importance - there's quite a lot of java gui programs out there and chances are that most of them won't work (at least if they somehow make use of awt/swing)

Revision history for this message
Matthias Klose (doko) wrote : Re: [Bug 86103] Re: azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

Lorenco Trichardt schrieb:
> Confirmed with Any Java Version I Tried.Any application on my system:
> Tried all :

it works with 5.

> Selection Alternative
> -----------------------------------------------
> 1 /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
> + 2 /usr/lib/j2re1.5-ibm/jre/bin/java
> 3 /usr/lib/j2sdk1.5-ibm/bin/java
> * 4 /usr/lib/jvm/java-6-sun/jre/bin/java
> 5 /usr/bin/gij-wrapper-4.1
>
> bummer ....
> I have Java dumps .... but looks like it should be easily replicated
>
> Using latest Feisty release....

Revision history for this message
Larry (larry-salibra) wrote :

This only seems to affect Java gui apps run on the local X server on feisty. Java gui apps running on feisty displaying to remote X servers work fine. Java gui apps running on other computers (non-feisty..edgy for example) displaying to feisty's X server also work fine.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the libxcb package has been modified to workaround that lock assertion for feisty, the bug will still need to be fixed though

Revision history for this message
Michael (m-gruys) wrote :

Which version of the libxcb package has been modified to workaround the lock assertion?
The current (newest) version "libx11-6_2%3a1.1.1-1ubuntu1_i386.deb" STILL has the 'c->xlib.lock' problem...

Revision history for this message
Larry (larry-salibra) wrote :

The lock assertion workaround doesn't work here (latest feisty as of comment post time) either.
Following instructions in the changelog:

larry@stig:~$ export LIBXCB_ALLOW_SLOPPY_LOCK=true
larry@stig:/opt/netbeans-5.5/bin$ ./netbeans
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)
larry@stig:/opt/netbeans-5.5/bin$

Revision history for this message
Frank Louwers (frank-openminds) wrote :

Confirmed that the workaround does NOT work, latest libxcb:

frank@tembo% apt-cache policy libxcb1 /home/frank
libxcb1:
  Installed: 1.0-1.1ubuntu1
  Candidate: 1.0-1.1ubuntu1

frank@tembo% zcat /usr/share/doc/libxcb1/changelog.Debian.gz | head /home/frank
libxcb (1.0-1.1ubuntu1) feisty; urgency=low

  [ Timo Aaltonen ]
  * debian/patches:
    - 100_allow_sloppy_lock.diff from Novell, workaround to the various
      'Assertion `c->xlib.lock' failed"' -bugs by setting an environment
      variable LIBXCB_ALLOW_SLOPPY_LOCK to any value and the check will
      simply be ignored.

Still crashes java applets in Firefox

Revision history for this message
Michael (m-gruys) wrote :

This morning the automatic update installed a new version which fixed the
BUG :-)
michael@michael-desktop:~$ apt-cache policy libxcb1
libxcb1:
  Geïnstalleerd: 1.0-1.1ubuntu2
  Kandidaat: 1.0-1.1ubuntu2
  Versietabel:
 *** 1.0-1.1ubuntu2 0
        500 http://nl.archive.ubuntu.com feisty/main Packages
        100 /var/lib/dpkg/status
michael@michael-desktop:~$

Congratulations good work!
Many thanks to all the hard working programmers.

2007/3/9, Frank Louwers <email address hidden>:
>
> Confirmed that the workaround does NOT work, latest libxcb:
>
> frank@tembo% apt-cache policy
> libxcb1 /home/frank
> libxcb1:
> Installed: 1.0-1.1ubuntu1
> Candidate: 1.0-1.1ubuntu1
>
>
> frank@tembo% zcat /usr/share/doc/libxcb1/changelog.Debian.gz |
> head /home/frank
> libxcb (1.0-1.1ubuntu1) feisty; urgency=low
>
> [ Timo Aaltonen ]
> * debian/patches:
> - 100_allow_sloppy_lock.diff from Novell, workaround to the various
> 'Assertion `c->xlib.lock' failed"' -bugs by setting an environment
> variable LIBXCB_ALLOW_SLOPPY_LOCK to any value and the check will
> simply be ignored.
>
>
> Still crashes java applets in Firefox
>
> --
> azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock'
> failed.
> https://launchpad.net/bugs/86103
>

Revision history for this message
Frank Louwers (frank-openminds) wrote :

Michel, indeed! The upgrade I installed this morning mentioned the fix, but didn't implement it. This afternoon 1.0-1.1ubuntu2 rolled in which fixed it, which means my online banking works again.

Revision history for this message
Sergey V. Udaltsov (sergey-udaltsov) wrote :

Seems to be ok for me

Revision history for this message
Ryba (sepatel) wrote :

For the record, the 1.0-1.1ubuntu2 version still does not fix the problem with other applications. For instance, commercial products like Neverwinter Nights still breask

21:15:51 /home/games/nwn$ ./nwn
nwmain: ../../src/xcb_lock.c:62: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed.
Aborted (core dumped)

I've done the export LIBXCB_ALLOW_SLOPPY_LOCK=true and still it breaks. How can I get a version of libxcb or whatever which does not do the assertions. Or how can I bypass it (my prefered solution would be to bypass rather then not do it at all).

Even though it is a bug, it is a commercial product and they are not going to be pushing out bug fixes for this type of stuff.

Bug Watch Updater (bug-watch-updater)
Changed in sun-java5:
status: Unconfirmed → Confirmed
Revision history for this message
Jamey Sharp (sharpone) wrote :

The Neverwinter Nights issue is unrelated to the bug originally reported here. The bug likely lies in a library that NWN is using, rather than in the game itself, and so is likely fixable. A backtrace would help in tracking down the cause of that failure.

Regarding the Sun Java bug, according to Josh Triplett:
> I worked with jcristau and christoph4 via IRC on #debian-x, and we managed to
> track down the problem with broken locking in Sun Java 1.5 and 1.6. It only
> occurs if Java finds the Xinerama extension, at which point it does something
> broken with locking and triggers the assertion. If Java never finds the
> Xinerama extension, it doesn't trigger the assertion for broken locking.
>
> The following workarounds address this problem:
>
> For sun-java5-bin:
> sed -i 's/XINERAMA/FAKEEXTN/g'
> +/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/xawt/libmawt.so
>
> For sun-java6-bin:
> sed -i 's/XINERAMA/FAKEEXTN/g'
> +/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
>
> The same fix (applied to the appropriate file) might work for other
> proprietary JDKs.

Revision history for this message
In , Son-two (son-two) wrote :
Download full text (3.5 KiB)

during investigation of Sun's bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 I've found that the cause of the problem is in XCB, not in Sun's code. I've developed the small test to demonstrate the problem. The test is very simple: it calls LockDisplay() and _XReply(), in usual situation it hangs because there is no replies, but on in bad it throws the assertion. To reproduce the problem you need to build the test on platform which doesn't have xcb and then run it on a platform with xcb.

Here is the test (made from source of Xinerama by removing most of the code):

#include <X11/Xlib.h>
#include <X11/Xlibint.h>
#include <X11/Xos.h>
#include <X11/Xutil.h>
#include "Xext.h" /* in ../include */
#include "extutil.h" /* in ../include */
#include "panoramiXext.h"
#include "panoramiXproto.h" /* in ../include */

#include <stdio.h>

static XExtensionInfo _panoramiX_ext_info_data;
static XExtensionInfo *panoramiX_ext_info = &_panoramiX_ext_info_data;
static /* const */ char *panoramiX_extension_name = PANORAMIX_PROTOCOL_NAME;

#define PanoramiXCheckExtension(dpy,i,val) \
  XextCheckExtension (dpy, i, panoramiX_extension_name, val)
#define PanoramiXSimpleCheckExtension(dpy,i) \
  XextSimpleCheckExtension (dpy, i, panoramiX_extension_name)

static int close_display();
static /* const */ XExtensionHooks panoramiX_extension_hooks = {
    NULL, /* create_gc */
    NULL, /* copy_gc */
    NULL, /* flush_gc */
    NULL, /* free_gc */
    NULL, /* create_font */
    NULL, /* free_font */
    close_display, /* close_display */
    NULL, /* wire_to_event */
    NULL, /* event_to_wire */
    NULL, /* error */
    NULL, /* error_string */
};
static XEXT_GENERATE_FIND_DISPLAY (find_display, panoramiX_ext_info,
                                   panoramiX_extension_name,
                                   &panoramiX_extension_hooks,
                                   0, NULL)
static XEXT_GENERATE_CLOSE_DISPLAY (close_display, panoramiX_ext_info)

Status XPanoramiXQueryVersion(
    Display *dpy,
    int *major_versionp,
    int *minor_versionp
)
{
/* XExtDisplayInfo *info = find_display (dpy); */
    xPanoramiXQueryVersionReply rep;
/* xPanoramiXQueryVersionReq *req; */

/* PanoramiXCheckExtension (dpy, info, 0); */

    LockDisplay (dpy);
/* GetReq (PanoramiXQueryVersion, req); */
/* req->reqType = info->codes->major_opcode; */
/* req->panoramiXReqType = X_PanoramiXQueryVersion; */
/* req->clientMajor = PANORAMIX_MAJOR_VERSION; */
/* req->clientMinor = PANORAMIX_MINOR_VERSION; */
    if (!_XReply (dpy, (xReply *) &rep, 0, xTrue)) {
        UnlockDisplay (dpy);
        SyncHandle ();
        return 0;
    }
    *major_versionp = rep.majorVersion;
    *minor_versionp = rep.minorVersion;
    UnlockDisplay (dpy);
    SyncHandle ();
    return 1;
}

...

Read more...

Revision history for this message
In , Josh Triplett (joshtriplett) wrote :

Reassigning to Xlib, changing summary, and bumping priority and severity.

Revision history for this message
In , Dbodom (dbodom) wrote :

Hello, same problem here.

Here is some useful information, if you need more, feel free to contact me.

bodom@hell:~$ java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

bodom@hell:~$ jconsole
jconsole: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

bodom@hell:~$ uname -a
Linux hell 2.6.21.3 #3 Sun Jun 3 07:32:57 CEST 2007 i686 GNU/Linux

Revision history for this message
In , Josh Triplett (joshtriplett) wrote :

After further discussion with other colleagues, we determined that this problem really does not lie in Xlib/XCB. As far as we can tell, the JDK statically links with a libXinerama built against Xlib without XTHREADS #defined. This makes LockDisplay() compile to nothing. (The test case given in this bug simulates the same setup.) However, the JDK dynamically links to the system Xlib, which normally does have XTHREADS on any modern system. This never represented a supported configuration, even well before XCB; you cannot use an extension library that doesn't use XTHREADS with an Xlib that does use XTHREADS. XCB just exposes the problem, because an XCB-based Xlib always uses XTHREADS, and it needs the LockDisplay and UnlockDisplay macros to call the locking hooks because it does additional XCB-related processing in those hooks; thus, it includes locking correctness assertions in lieu of failing mysteriously when a library fails to do proper locking.

I spoke with Tom Marble of Sun about this at OSCON, and he and I both agreed that this bug lies with the JDK; it needs to either dynamically link to the system libXinerama, or statically link a libXinerama that uses XTHREADS (to *hopefully* match the system Xlib it dynamically links), or statically link an Xlib without XTHREADS. Xlib and extension libraries like libXinerama must agree about XTHREADS.

Thus, resolving as NOTOURBUG. I will post the same thing to the Sun bug, and Tom Marble assured me he would look into getting this fixed in the JDK.

Revision history for this message
In , Son-two (son-two) wrote :

I have a question:

in the test I do nothing except calling LockDisplay() and _XReply() and I do not
force linker to link LockDisplay() statically. As far as I understand the problem
is that LockDisplay() is macro and so it is always statically linked. Am I right?

If so, how can I workaround this? I see the only way recompile the test on target
platform. I do not think that use of Xlib with XTHREADS is a good idea, because I do not need them and Xlib on target platform may not use them too.

Revision history for this message
In , Alan Coopersmith (alan-coopersmith) wrote :

Note that "XTHREADS" does not mean Xlib will suddenly use threads, it really means
"make Xlib thread safe, by making LockDisplay() etal into real lock calls instead
of no-ops."

If Xlib isn't built with XTHREADS defined, it's not thread safe, so would be
unsafe to use in the highly threaded Java at all, wouldn't it?

Revision history for this message
In , Josh Triplett (joshtriplett) wrote :

Yes, or to put it another way, not defining XTHREADS means "run a bit faster by disregarding thread safety".

In theory even threaded programs can use a non-XTHREADS Xlib if they only call Xlib and X extension functions from a single thread; however, Xlib and every X extension library must agree on the value of XTHREADS, and this bug arises when they do not.

Revision history for this message
In , cosine (mvanross) wrote :

I get the same error message with xv compiled from source.
Isn't this supposed to work?

ldd ./xv

        linux-gate.so.1 => (0x0012d000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x0012e000)
        libm.so.6 => /lib/libm.so.6 (0x0022a000)
        libc.so.6 => /lib/libc.so.6 (0x00253000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00b1f000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00b23000)
        libdl.so.2 => /lib/libdl.so.2 (0x003ab000)
        /lib/ld-linux.so.2 (0x00110000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00b41000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00b17000)

Revision history for this message
In , cosine (mvanross) wrote :

Oops sorry about that.
It is working now after an update.

Revision history for this message
Dirk R. Gently (partridge-todd) wrote :

NWN worked fine for me until I added the "Undrentide" expansion pack. Seems related to the /nwn/en/miles/libmss.so.6.5.2 file.

Revision history for this message
Dirk R. Gently (partridge-todd) wrote :

A library is the issue? NWN worked fine for me until I added the "Undrentide" expansion pack. Seems related to the /nwn/en/miles/libmss.so.6.5.2 file.

Revision history for this message
Jamey Sharp (sharpone) wrote : Re: [Bug 86103] Re: azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

On 10/16/07, Dirk R. Gently <email address hidden> wrote:
> A library is the issue? NWN worked fine for me until I added the
> "Undrentide" expansion pack. Seems related to the
> /nwn/en/miles/libmss.so.6.5.2 file.

I don't have NWN so I can't reproduce your issue. It's unrelated to
the Java bug (which Sun has acknowledged and they intend to release a
fix), so would you open a new bug report and include at least the
output of `ldd /nwn/en/miles/libmss.so.6.5.2`, and preferably a
backtrace from gdb?

Revision history for this message
Luke Hoersten (lukehoersten) wrote :

Googling the error shows that this is a widespread problem. Sun claims it's already fixed:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
Perhaps the package just needs to be updated or patched?

Revision history for this message
Jamey Sharp (sharpone) wrote :

On 10/23/07, Luke Hoersten <email address hidden> wrote:
> Googling the error shows that this is a widespread problem. Sun claims it's already fixed:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
> Perhaps the package just needs to be updated or patched?

Sun reports the Java bug is fixed in JDK7 beta 22:

http://download.java.net/jdk7/changes/jdk7-b22.html

However, the release notes for JDK5 and JDK6 do not mention fixes for
this bug, as far as I can tell.

The fix was straightforward, since correct code was already being used
in Solaris builds. But the Sun engineers were concerned about making
sure it passed all of their test suite, which is why it took a while.
I don't know if we'll see a similar fix from the JDK5 and JDK6 teams,
but I sure hope so.

Revision history for this message
Luke Hoersten (lukehoersten) wrote :

I don't think it's just the JDK. Many people trying to use the JRE are having the same problem (like this current thread, Amadeus Foudray is trying to use Azureus). Waiting for a Sun Java 7 package doesn't really seem like a viable solution for people who not only want to make Java apps, but run them. Does anyone know of a workaround or patch for this problem?

Here's a list of some other bug reports:

https://bugs.freedesktop.org/show_bug.cgi?id=8521
https://bugs.freedesktop.org/show_bug.cgi?id=8582

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400440
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400441
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400442
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400443
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400443
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400445
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400446

Revision history for this message
Jamey Sharp (sharpone) wrote :

On 10/27/07, Luke Hoersten <email address hidden> wrote:
> I don't think it's just the JDK. Many people trying to use the JRE are
> having the same problem ...

Yes, this is a generic Java issue. The JRE is a subset of the JDK that
contains almost all the same code. The distinction is too troublesome
for normal discussion.

> Does anyone know of a workaround or patch for this problem?

Sure. You can turn off Xinerama support in your X server, or as Josh
Triplett documented in June, you can effectively disable Xinerama
support in Java:

https://bugs.freedesktop.org/show_bug.cgi?id=9336#c15

Upstream libxcb also now has a variant of the Novell sloppy lock patch,
so that you can set an environment variable to disable the asserts when
you run broken applications, like Java before JDK7 beta 22.

Furthermore, experimental packages of JDK7 are available for Ubuntu
Gutsy and are expected to work with Debian as well.

http://lists.debian.org/debian-java/2007/08/msg00028.html

> Here's a list of some other bug reports:

All the bug reports you listed are already fixed, both upstream and in
Debian, Gentoo, and I assume in Ubuntu and elsewhere. None of them are
relevant to the Java issue. Why do you bring them up?

Revision history for this message
James Stansell (jamesstansell) wrote :

On 10/27/07, Jamey Sharp wrote:
>
> you run broken applications, like Java before JDK7 beta 22.
>
> Furthermore, experimental packages of JDK7 are available for Ubuntu
> Gutsy ...
>

Ubuntu Gutsy repositories have the icedtea packages based on JDK7 beta 21.
The Hardy archives have the beta 22 packages.

https://launchpad.net/ubuntu/+source/icedtea-java7/

Revision history for this message
Jamey Sharp (sharpone) wrote :

On 10/27/07, James Stansell <email address hidden> wrote:
> Ubuntu Gutsy repositories have the icedtea packages based on JDK7 beta 21.
> The Hardy archives have the beta 22 packages.

Fascinating, and good for them! I didn't know Ubuntu had icedtea
integrated in any sense yet. For the record, though, the repository I
referred to has icedtea beta 22 built for Gutsy (on amd64).

Revision history for this message
Kow (kow) wrote :
Download full text (43.2 KiB)

#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002b3278d0e891, pid=6983, tid=1074792784
#
# Java VM: IcedTea 64-Bit Server VM (1.7.0-b22 mixed mode linux-amd64)
# Problematic frame:
# V [libjvm.so+0x5cb891]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

--------------- T H R E A D ---------------

Current thread (0x0000000000609000): JavaThread "main" [_thread_in_vm, id=6986, stack(0x0000000040000000,0x0000000040101000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x0000000000000000

Registers:
RAX=0x0000000000609000, RBX=0x0000000000609000, RCX=0x0000000000609000, RDX=0x00002b3277fca280
RSP=0x00000000400fd5e0, RBP=0x00000000400fd610, RSI=0x0000000040100a30, RDI=0x0000000000000001
R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x00002aaaabd84783, R11=0x00002b3278c7dab0
R12=0x00b85a7000000009, R13=0x0000000000609000, R14=0x00000000400fd6b0, R15=0x00002b3279114a20
RIP=0x00002b3278d0e891, EFL=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000000
  TRAPNO=0x000000000000000d

Top of Stack: (sp=0x00000000400fd5e0)
0x00000000400fd5e0: 00000000400fd700 00002aaad8944fd0
0x00000000400fd5f0: 0000000000000101 00002aaad8944fd0
0x00000000400fd600: 00000000400fd6b0 0000000000609000
0x00000000400fd610: 00000000400fd680 00002aaaabd847b0
0x00000000400fd620: 0000000000baf408 0000000000baf428
0x00000000400fd630: 0000000000baf430 0000000000baf430
0x00000000400fd640: 00000000400fd640 0000000000000000
0x00000000400fd650: 00000000400fd6b0 00002aaad8948a48
0x00000000400fd660: 0000000000000000 00002aaad8944fd0
0x00000000400fd670: 0000000000000000 00000000400fd6a0
0x00000000400fd680: 00000000400fd700 00002aaaabd78342
0x00000000400fd690: 0000000000000000 00002aaaabd80cee
0x00000000400fd6a0: 00b85a7000000009 0000000000baf410
0x00000000400fd6b0: 00002aaabcca0ab0 00000000000000ff
0x00000000400fd6c0: 00000000400fd6c0 00002aaad95f1a57
0x00000000400fd6d0: 00000000400fd718 00002aaad95f4f20
0x00000000400fd6e0: 0000000000000000 00002aaad95f1a70
0x00000000400fd6f0: 00000000400fd6a0 00000000400fd710
0x00000000400fd700: 00000000400fd760 00002aaaabd782b8
0x00000000400fd710: 00b85a7000000009 00002aaaabd781e9
0x00000000400fd720: 00000000400fd720 00002aaad95f1b2c
0x00000000400fd730: 00000000400fd780 00002aaad95f4f20
0x00000000400fd740: 0000000000000000 00002aaad95f1b50
0x00000000400fd750: 00000000400fd710 00000000400fd770
0x00000000400fd760: 00000000400fd7c8 00002aaaabd782b8
0x00000000400fd770: 0000000000000009 00b85a7000000000
0x00000000400fd780: 0000000000000000 00000000400fd788
0x00000000400fd790: 00002aaad94cd331 00000000400fd858
0x00000000400fd7a0: 00002aaad94d4678 0000000000000000
0x00000000400fd7b0: 00002aaad94cd5c0 00000000400fd770
0x00000000400fd7c0: 00000000400fd860 00000000400fd8a0
0x00000000400fd7d0: 00002aaaabd7811a 0000000000000000

Instructions: (pc=0x00002b3278d0e891)
0x00002b3278d0e881: 00 00 8b 38 e8 a6 ed b6 ff c6 80 44 02 00 00 01
0x00002b3278d0e891: 45 0f b6 34 24 c6 80 44 02 00 00 00 48 8b 5b 48

Stack: [0x0000000040000000,0x00000000...

Revision history for this message
Kow (kow) wrote :

The above error occurs on hardy using icedtea7. If i use Sun's Java implementation I get the originally reported error. Perhaps this trace will provide more details.

Revision history for this message
Kow (kow) wrote :

If I reapply the "allow sloppy locks" workaround patch to libxcb the problem is gone. I'm guessing this was removed because the thought was this was fixed upstream?

Revision history for this message
In , Wez (wez) wrote :

This does appear to be a bug in XCB, in that there is no reason why a single-threaded binary that makes use of an X extension shouldn't run against both XTHREAD and non-XTHREAD copies of Xlib without difficulty.

Revision history for this message
In , Josh Triplett (joshtriplett) wrote :

(In reply to comment #9)
> This does appear to be a bug in XCB, in that there is no reason why a
> single-threaded binary that makes use of an X extension shouldn't run against
> both XTHREAD and non-XTHREAD copies of Xlib without difficulty.

That doesn't describe the problem here. An arbitrary single-threaded binary using an X extension can work with either an XTHREADS Xlib and XTHREADS extension or a no-XTHREADS Xlib and a no-XTHREADS extension. However, that does not mean it will work with a no-XTHREADS extension and an XTHREADS Xlib or vice-versa. Nothing ever said that would work, either before or after XCB.

Revision history for this message
In , Wez (wez) wrote :

(In reply to comment #10)
> (In reply to comment #9)
> > This does appear to be a bug in XCB, in that there is no reason why a
> > single-threaded binary that makes use of an X extension shouldn't run against
> > both XTHREAD and non-XTHREAD copies of Xlib without difficulty.
> That doesn't describe the problem here. An arbitrary single-threaded binary
> using an X extension can work with either an XTHREADS Xlib and XTHREADS
> extension or a no-XTHREADS Xlib and a no-XTHREADS extension. However, that
> does not mean it will work with a no-XTHREADS extension and an XTHREADS Xlib or
> vice-versa. Nothing ever said that would work, either before or after XCB.

The extension is part of the X server - whether or not it's thread-aware depends upon whether the server (or module) was build to be, which is entirely independent of whether an individual client's Xlib implementation is thread-aware.

The situation I'm describing is an application which can use a particular X extension if present, and which has the code to do that built-in - it's not loading a library from the host system in order to access the extension, it's doing it itself via the installed Xlib. Even if it were to use a dynamic library to access the extension, how is the library-builder to know whether the particular Xlib installed on that host system is thread-capable or not?

Why _should_ the client-side library for the extension care whether Xlib is thread-capable? If the client-side library is built to be thread-capable but Xlib is not then XInitThreads() will fail at application startup and the app will be single-threaded, so Xlib should be happy & the locking operations a thread-capable version provides are no-ops. If the client-side library is not thread-capable and it's used by an application that never calls XinitThreads() then why shouldn't a thread-capable Xlib support that?

Revision history for this message
In , Daniel Stone (daniels) wrote :

(In reply to comment #11)
> The extension is part of the X server - whether or not it's thread-aware
> depends upon whether the server (or module) was build to be, which is entirely
> independent of whether an individual client's Xlib implementation is
> thread-aware.

'Extensions' aren't thread-aware. They're just a bit of wire protocol and some code on the server which processes client requests. The server obviously has no way to know if a client's using threads, and doesn't care.

> The situation I'm describing is an application which can use a particular X
> extension if present, and which has the code to do that built-in - it's not
> loading a library from the host system in order to access the extension, it's
> doing it itself via the installed Xlib. Even if it were to use a dynamic
> library to access the extension, how is the library-builder to know whether the
> particular Xlib installed on that host system is thread-capable or not?

The solution is brutally simple: _share_ shared libraries. You're attempting to solve a distributor's problem as an ISV, and it's not working. If you want to distribute X client libraries, distribute Xlib and all your extension libraries. Don't just do half of it and be surprised when it doesn't work.

> Why _should_ the client-side library for the extension care whether Xlib is
> thread-capable?

Because the entire Xlib stack sucks, which is why we're trying our hardest to get rid of Xlib?

> If the client-side library is built to be thread-capable but
> Xlib is not then XInitThreads() will fail at application startup and the app
> will be single-threaded, so Xlib should be happy & the locking operations a
> thread-capable version provides are no-ops. If the client-side library is not
> thread-capable and it's used by an application that never calls XinitThreads()
> then why shouldn't a thread-capable Xlib support that?

Because building with XTHREADS or not determines how the ABI is managed. I don't know anyone who builds without XTHREADS support these days. If your concern is about old systems, then, well, they're immutable, and we can't exactly just disable threads for all systems.

So, it comes down to this: if you really want to support ancient systems, distribute Xlib and all your extension libraries. If you don't, then build your libraries with XTHREADS support, as everyone builds Xlib with XTHREADS. Everyone wins.

We can't fix Xlib's API/ABI (both are set in stone for obvious reasons), nor can we do anything about the inadequacies of various distributions or systems. If you want to patch these up yourself, please feel free, but don't be surprised if it all falls apart.

Our position is that this bug is NOTOURBUG. If you would like to fix this once and for all, please investigate XCB. Thanks.

Revision history for this message
Jamey Sharp (sharpone) wrote : Re: [Bug 86103] Re: azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

On 11/12/07, Kow <email address hidden> wrote:
> If I reapply the "allow sloppy locks" workaround patch to libxcb the
> problem is gone.

By "the problem", you mean the stack trace you just reported? That's
very strange. I can't find anything related to Xlib or XCB near the top
of the stack traces you provided, though the memory map confirms that
you are using XCB.

A variant of the "allow sloppy locks" patch has been committed upstream
in XCB and is in the recent 1.1 release, so hopefully it will make it
into Ubuntu in the near future. I dunno, maybe they're waiting for me to
roll a new Debian package, which I haven't had time to do yet. :-/

Revision history for this message
In , Wez (wez) wrote :
Download full text (4.9 KiB)

(In reply to comment #12)
> (In reply to comment #11)
> 'Extensions' aren't thread-aware. They're just a bit of wire protocol and some
> code on the server which processes client requests. The server obviously has
> no way to know if a client's using threads, and doesn't care.

Yes. That's the point I was making, in response to Josh talking about "XTHREADS extensions". :)

> > The situation I'm describing is an application which can use a particular X
> > extension if present, and which has the code to do that built-in - it's not
> > loading a library from the host system in order to access the extension, it's
> > doing it itself via the installed Xlib. Even if it were to use a dynamic
> > library to access the extension, how is the library-builder to know whether the
> > particular Xlib installed on that host system is thread-capable or not?
> The solution is brutally simple: _share_ shared libraries. You're attempting
> to solve a distributor's problem as an ISV, and it's not working. If you want
> to distribute X client libraries, distribute Xlib and all your extension
> libraries. Don't just do half of it and be surprised when it doesn't work.

There are no shared libraries involved in the system I'm describing, nor am I distributing any. I'm talking about a single-binary, single-threaded application, which dynamically links to whichever "Xlib" is installed, whether that be Xlib or XCB, XTHREAD-ed or not.

The application has a little code in it to talk to a particular X extension via the installed "Xlib". With Xlib, this works fine whether Xlib is XTHREAD-ed or not - the extension client-side code in the application is built with XTHREADS and so does not attempt to call any locking functions. Because the application never calls XInitThreads(), Xlib doesn't create locking structures for displays, which routines like _XReply() assume means that locking isn't required.

> Because building with XTHREADS or not determines how the ABI is managed.

Can you give an example of what you mean by that? An admittedly brief glance at Xlib suggests that XTHREADS-controlled APIs such as LockDisplay() boil down to a check for locking structures followed by a per-display lock-function call, and that those structures default to null, even for non-XTHREADS builds, and are filled out only when XInitThreads() succeeds. If that were true, it would always be safe to build an extension library with XTHREADS defined, incurring only the minor performance hit of a potentially unnecessary pointer test each Lock/UnlockDisplay(), in return for compatibility with both XTHREADS & non-XTHREADS Xlib/XCB.

> I
> don't know anyone who builds without XTHREADS support these days. If your
> concern is about old systems, then, well, they're immutable, and we can't
> exactly just disable threads for all systems.
> So, it comes down to this: if you really want to support ancient systems,
> distribute Xlib and all your extension libraries. If you don't, then build
> your libraries with XTHREADS support, as everyone builds Xlib with XTHREADS.
> Everyone wins.
> We can't fix Xlib's API/ABI (both are set in stone for obvious reasons), nor
> can we do anything about t...

Read more...

Revision history for this message
In , Wez (wez) wrote :

Sorry, typo:
...the extension client-side code in the application is built with XTHREADS...

should end "without XTHREADS"

Revision history for this message
In , Josh Triplett (joshtriplett) wrote :
Download full text (6.1 KiB)

(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > 'Extensions' aren't thread-aware. They're just a bit of wire protocol and some
> > code on the server which processes client requests. The server obviously has
> > no way to know if a client's using threads, and doesn't care.
>
> Yes. That's the point I was making, in response to Josh talking about
> "XTHREADS extensions". :)

s/XTHREADS extension/XTHREADS extension client implementation (library or built into a program)/g, then.

> > > The situation I'm describing is an application which can use a particular X
> > > extension if present, and which has the code to do that built-in - it's not
> > > loading a library from the host system in order to access the extension, it's
> > > doing it itself via the installed Xlib. Even if it were to use a dynamic
> > > library to access the extension, how is the library-builder to know whether the
> > > particular Xlib installed on that host system is thread-capable or not?
> > The solution is brutally simple: _share_ shared libraries. You're attempting
> > to solve a distributor's problem as an ISV, and it's not working. If you want
> > to distribute X client libraries, distribute Xlib and all your extension
> > libraries. Don't just do half of it and be surprised when it doesn't work.
>
> There are no shared libraries involved in the system I'm describing, nor am I
> distributing any. I'm talking about a single-binary, single-threaded
> application, which dynamically links to whichever "Xlib" is installed, whether
> that be Xlib or XCB, XTHREAD-ed or not.

'no shared libraries....dynamically links to whichever "Xlib"'? You have a shared library: Xlib. You don't distribute it, so you rely on the one on the system, which means you have to match its definition of XTHREADS, or rely on other shared libraries on the system which will match it.

> The application has a little code in it to talk to a particular X extension via
> the installed "Xlib". With Xlib, this works fine whether Xlib is XTHREAD-ed or
> not - the extension client-side code in the application is built with XTHREADS
[from your later reply, "without XTHREADS"]
> and so does not attempt to call any locking functions. Because the application
> never calls XInitThreads(), Xlib doesn't create locking structures for
> displays, which routines like _XReply() assume means that locking isn't
> required.

Not correct. If your code builds without XTHREADS, _XReply won't even *try* to use locking functions if available. This means that if Xlib, or other extension libraries, or any other component linked into your application *does* use XTHREADS, it will not work. If you want to build without XTHREADS, you need to ship all the rest of the libraries you need without XTHREADS, either by statically linking or by shipping your own copies of shared libraries.

> > Because building with XTHREADS or not determines how the ABI is managed.
>
> Can you give an example of what you mean by that? An admittedly brief glance
> at Xlib suggests that XTHREADS-controlled APIs such as LockDisplay() boil down
> to a check for locking structures followed by a per-disp...

Read more...

Revision history for this message
In , Wez (wez) wrote :
Download full text (4.6 KiB)

(In reply to comment #15)
> > The application has a little code in it to talk to a particular X extension via
> > the installed "Xlib". With Xlib, this works fine whether Xlib is XTHREAD-ed or
> > not - the extension client-side code in the application is built with XTHREADS
> [from your later reply, "without XTHREADS"]
> > and so does not attempt to call any locking functions. Because the application
> > never calls XInitThreads(), Xlib doesn't create locking structures for
> > displays, which routines like _XReply() assume means that locking isn't
> > required.
> Not correct. If your code builds without XTHREADS, _XReply won't even *try* to
> use locking functions if available.
 [snip]

I'm afraid that you are mistaken. _XReply() is implemented in Xlib - whether or not it attempts to perform locking depends upon whether Xlib was build with XTHREADS defined, not on the calling code.

> This means that if Xlib, or other
> extension libraries, or any other component linked into your application *does*
> use XTHREADS, it will not work. If you want to build without XTHREADS, you
> need to ship all the rest of the libraries you need without XTHREADS, either by
> statically linking or by shipping your own copies of shared libraries.

I've never yet seen a single-threaded X application that is built with XTHREADS defined, yet you seem to be saying that running such an application against an XTHREADS "Xlib" isn't supported.

> > > Because building with XTHREADS or not determines how the ABI is managed.
> >
> > Can you give an example of what you mean by that? An admittedly brief glance
> > at Xlib suggests that XTHREADS-controlled APIs such as LockDisplay() boil down
> > to a check for locking structures followed by a per-display lock-function call,
> > and that those structures default to null, even for non-XTHREADS builds, and
> > are filled out only when XInitThreads() succeeds. If that were true, it would
> > always be safe to build an extension library with XTHREADS defined, incurring
> > only the minor performance hit of a potentially unnecessary pointer test each
> > Lock/UnlockDisplay(), in return for compatibility with both XTHREADS &
> > non-XTHREADS Xlib/XCB.
> And in fact new Xlib, with Xlib/XCB, does always #define XTHREADS.
> To answer your first question: the ABI of Xlib includes how you call its
> functions and manipulate its data structures, and the Xlibint macros define how
> you do that. Having XTHREADS defined or not defined changes this, and thus
> changes the ABI of Xlib.

In particular it changes LockDisplay() & UnlockDisplay() from being no-ops to checking for per-display lock_fns & using them if present. Because Displays always have a lock_fns field regardless of whether XTHREADS is defined, the XTHREADS-ed LockDisplay() & UnlockDisplay() implementations are safe to use even with non-XTHREADS "Xlib". It's only when the macros & members whose names start with an underscore, e.g. _XLockMutex(), are used that a *requirement* for the XTHREADS-ed "Xlib" ABI is created.

> > The problem appears to be that XCB's locking design assumes that calling code
> > will always call the display's "Xlib" lock & unlock functions if t...

Read more...

Revision history for this message
Saivann Carignan (oxmosys) wrote :

A new azureus release version 2.5.0.4-1ubuntu3~gutsy1 has been released in Linux Ubuntu Gutsy Backports. Can you install it and confirm if you still can reproduce the bug?

Revision history for this message
In , Jamey-minilop (jamey-minilop) wrote :

(In reply to comment #16)
> I'm afraid that you are mistaken. _XReply() is implemented in Xlib -
> whether or not it attempts to perform locking depends upon whether
> Xlib was build with XTHREADS defined, not on the calling code.

True.

> I've never yet seen a single-threaded X application that is built with
> XTHREADS defined, yet you seem to be saying that running such an
> application against an XTHREADS "Xlib" isn't supported.

Only code using Xlibint.h matters. Applications (almost) never use
Xlibint.h. Gdk and the various client-side extension implementations are
the only code I'm aware of that we need to concern ourselves with. For
those components, the question of whether the XTHREADS definition
matches the one in Xlib matters.

> > > > Because building with XTHREADS or not determines how the ABI is
> > > > managed.
> > >
> > > Can you give an example of what you mean by that?

There are some global variables in Xlib that are declared only if
XTHREADS is turned on, and are visible to Xlibint.h-using software. Code
using _XLockMutex, _XUnlockMutex, _XCreateMutex, and _XFreeMutex will
encounter this problem. Of the core X.org libraries, this affects
libXcomposite, libXcursor, libXdamage, libXext, libXfixes, libXp, and
libXrender. Google Code Search also finds it in a copy of Motif.

I believe that's the only case where the ABI is different.

> In particular it changes LockDisplay() & UnlockDisplay() from being
> no-ops to checking for per-display lock_fns & using them if present.
> Because Displays always have a lock_fns field regardless of whether
> XTHREADS is defined, the XTHREADS-ed LockDisplay() & UnlockDisplay()
> implementations are safe to use even with non-XTHREADS "Xlib". It's
> only when the macros & members whose names start with an underscore,
> e.g. _XLockMutex(), are used that a *requirement* for the XTHREADS-ed
> "Xlib" ABI is created.

That appears to be true, in practice.

> It seems that building extension client-side code with XTHREADS
> defined & which doesn't try to use the "private" XTHREADS-ABI macros &
> members is sufficient to make it XTHREADS & non-XTHREADS compatible.

I would be happy with all libraries being built with XTHREADS enabled,
yes. In practice that ensures compatibility regardless, because Xlib is
always built with XTHREADS enabled too, and has been for some time.

> I'm basing all of this on examination of the libX11 code & headers, of
> course - could someone point me to the official ABI document?

Hah!

Oh, you were probably serious. I think the official ABI document for
Xlib these days is <email address hidden>.

Regarding Xlib ABI, we muddle through the best we can.

Revision history for this message
Cameron Braid (cameron-braid) wrote : Re: [Bug 86103] Re: azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

I gave up a while ago and installed the latest version from sourceforge

I just installed 2.5.0.4-1ubuntu3~gutsy1 :

dpkg -l | grep azureus
ii azureus 2.5.0.4-1ubuntu3~gutsy1
BitTorrent client

all seems good so far - though I havn't been trying it for long.

Cheers,

Cameron

On Nov 21, 2007 8:14 PM, Saïvann Carignan <email address hidden> wrote:

> A new azureus release version 2.5.0.4-1ubuntu3~gutsy1 has been released
> in Linux Ubuntu Gutsy Backports. Can you install it and confirm if you
> still can reproduce the bug?
>
> --
> azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock'
> failed.
> https://bugs.launchpad.net/bugs/86103
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Saivann Carignan (oxmosys) wrote :

Thanks for testing this. Can someone else from this bug report confirm that the latest Gutsy backport release fix that problem?

Revision history for this message
Saivann Carignan (oxmosys) wrote :

Since it seems to work for everybody, I set this bug as a duplicate of bug #57875 but feel free to cancel this if you still can reproduce the bug with latest packages.

Thanks to everybody work worked on this.

Revision history for this message
In , Wez (wez) wrote :

(In reply to comment #17)
> Only code using Xlibint.h matters. Applications (almost) never use
> Xlibint.h. Gdk and the various client-side extension implementations are
> the only code I'm aware of that we need to concern ourselves with. For
> those components, the question of whether the XTHREADS definition
> matches the one in Xlib matters.
 [snip]
> > In particular it changes LockDisplay() & UnlockDisplay() from being
> > no-ops to checking for per-display lock_fns & using them if present.
> > Because Displays always have a lock_fns field regardless of whether
> > XTHREADS is defined, the XTHREADS-ed LockDisplay() & UnlockDisplay()
> > implementations are safe to use even with non-XTHREADS "Xlib". It's
> > only when the macros & members whose names start with an underscore,
> > e.g. _XLockMutex(), are used that a *requirement* for the XTHREADS-ed
> > "Xlib" ABI is created.
> That appears to be true, in practice.
 [snip]
> > I'm basing all of this on examination of the libX11 code & headers, of
> > course - could someone point me to the official ABI document?
> Hah!
> Oh, you were probably serious. I think the official ABI document for
> Xlib these days is <email address hidden>.
> Regarding Xlib ABI, we muddle through the best we can.

What I was getting at is that the Xlib ABI is defined by, well, the Xlib ABI!

There are two "special cases" in conflict, which lead to the lock assertion issue that we've encountered:

1. Single-threaded applications with Xlib-based extension client-side code in them, compiled without XTHREADS defined.
2. Multi-threaded applications with a single Xlib client thread & one or more XCB client threads.

The problem arises from the decision to support (2) and the particular implementation which has been chosen, for the reasons we've discussed.

It seems to me that both (1) and (2) are unlikely scenarios, but there are evidently several applications which fall into (1), while (2) will presumably only arise in the special case where a single-threaded Xlib application loads a DLL that spawns threads to talk to the X server using XCB. I'd therefore question how likely (2) is to be useful, and therefore question the decision to break (admittedly internal(ish)) ABI-compatibility with classic Xlib.

Revision history for this message
Mikael Nilsson (mini) wrote :

This has appeared for me on upgrade to hardy. I did not have this issue before upgrading.

It also affects the upstream version installed in my home directory.

Revision history for this message
Mikael Nilsson (mini) wrote :

Crash on hardy using java 5 and 6, no crash with icedtea.

java: xcb_xlib.c:82: xcb_xlib_unlock: Försäkran "c->xlib.lock" falsk.

Revision history for this message
Bartek Szopka (bartoszopka) wrote :

I have similar problem on Hardy Alpha with Java 6.
When I try to run WEKA software I get:

~/Desktop/weka-3-5-6% java -jar weka.jar
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb5465767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb54658b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb54b72ed]
#3 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/xawt/libmawt.so [0xb55b264e]
#4 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/xawt/libmawt.so [0xb5590f97]
#5 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/xawt/libmawt.so [0xb5591248]
#6 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0xb559154f]
#7 [0xb5d6068e]
#8 [0xb5d58edd]
#9 [0xb5d58edd]
#10 [0xb5d56243]
#11 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/client/libjvm.so [0x620bc6d]
#12 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/client/libjvm.so [0x630a828]
#13 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/client/libjvm.so [0x620bb00]
#14 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/client/libjvm.so(JVM_DoPrivileged+0x34b) [0x62619bb]
#15 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7d7196d]
#16 [0xb5d6068e]
#17 [0xb5d58d77]
#18 [0xb5d56243]
#19 /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/client/libjvm.so [0x620bc6d]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
zsh: abort (core dumped) java -jar weka.jar

In this post here:
http://www.usalug.org/phpBB2/viewtopic.php?p=101247&sid=5b102b0d32bd564cbeb27c949980b5ff
I found solution about using
export LIBXCB_ALLOW_SLOPPY_LOCK=true

It seems to be working. After setting up this variable application runs.
It still throws a lot of stuff to console (see attachment), but it runs.

Revision history for this message
In , Sandmann (sandmann) wrote :

This bug has to be fixed.

Xlib is an old and widespread library, and there is tons of existing and *working* code that needs to be kept working and can't be recompiled.

We can argue until the cows come home about whose bug it is, but it doesn't matter. This is an ABI breakage: apps that worked before don't work now.

Nobody serious about compatibility can ship xcb with that assertion in place. It has to go away.

Revision history for this message
In , Josh Triplett (joshtriplett) wrote :

Things that happened to work with some versions of Xlib != things that Xlib supported. If you use Xlibint to write an X extension, regardless of whether that extension lives in a library or directly in a program, your extension code must match the system Xlib's idea about threading. This held true for Xlib regardless of whether any particular version of Xlib let you get away with not doing it; Xlib has in the past had notoriously lax ideas about threading.

Xlibint has existed for a long time, and people have used it; we do understand that has for some time formed part of the "public" API/ABI of Xlib. However, that doesn't make every detail in Xlibint part of the ABI. For example, Xlib/XCB, as well as older versions of Xlib, have extended the Display structure, so you cannot count on sizeof(Display) never changing. That does not represent part of the ABI, despite the fact that changing it could potentially break code which made assumptions about sizeof(Display), because code should not make assumptions about sizeof(Display). The same applies to the locking hooks; you must check and use them, and you must not simply assume that Xlib will not set them if you don't call XInitThreads.

As you have suggested, building your extension code with XTHREADS may work with older Xlibs that do not use XTHREADS. However, building your extension code without XTHREADS will break with an XTHREADS Xlib. I understand your argument that older versions of Xlib didn't actually use internal locking and unlocking code if you didn't call XInitThreads(), and thus you could get away without even trying to call them; however, that does not mean that you do not need to call the macros which check for the internal lock and unlock function pointers and call them if set.

Revision history for this message
In , Wez (wez) wrote :

(In reply to comment #20)
> Things that happened to work with some versions of Xlib != things that Xlib
> supported.

Yes and no. As previously discussed, the only two definitions of the Xlib ABI are the classic Xlib implementation, and the one in Keith Packard's head. I think the XCB approach of trying to match the ABI as per the contents of Keith Packard's head is a very good one, but at the same time sandmann is justified in complaining that changing the ABI from the one implemented by classic Xlib breaks lots of stuff in ways that aren't easily reparable.

> If you use Xlibint to write an X extension, regardless of whether
> that extension lives in a library or directly in a program, your extension code
> must match the system Xlib's idea about threading.

In the Xlib ABI in Keith Packard's head, I assume that's true, and it certainly seems reasonable. The fact remains, however, that the ABI provided by classic Xlib implements different behaviour for users of Xlibint functionality to the XCB Xlib. Changes in ABI, even just from as-implemented to as-intended, should really be accompanied by a library version change, so that even if the new behaviour becomes the default, the older version is still available to older applications. Linux distributions, for example, can then provide the older version as an optional install to allow old (broken) apps to run properly, or symlink it to the new version to force old (broken) apps to show up as broken.

[snip]

> As you have suggested, building your extension code with XTHREADS may work with
> older Xlibs that do not use XTHREADS. However, building your extension code
> without XTHREADS will break with an XTHREADS Xlib. I understand your argument
> that older versions of Xlib didn't actually use internal locking and unlocking
> code if you didn't call XInitThreads(), and thus you could get away without
> even trying to call them; however, that does not mean that you do not need to
> call the macros which check for the internal lock and unlock function pointers
> and call them if set.

I was the one asking about the XTHREADS issue, not sandmann, actually. As we've established, the issue here is that the difference in behaviour between classic Xlib and XCB Xlib constitutes a change in the presented ABI. Whether that's from as-implemented to as-intended behaviour is irrelevant if the result is that many programs relying on the old behaviour won't work with the new implementation. My view is that this is really a problem with for the Linux distributions to sort out, and of course it doesn't affect my particular project since I can rebuild with XTHREADS to get the required behaviour, but there are going to be people who need to run (broken) legacy apps who will find that they also need XCB-based apps in future, and can't install compatible libraries for both, which wouldn't have been a problem with a library version bump.

Revision history for this message
In , Sandmann (sandmann) wrote :

ABI compatibility is not a matter of black and white, but even if it were, it certainly is not defined by what's in Keith Packard's head.

The whole *POINT* of an ABI is to keep applications working without recompiling them. And it's not a matter of "getting away with it with certain versions". They worked with *all* versions until you broke them.

Like it or not, the ABI is defined by what existing applications do.

If you still refuse to fix this bug, I'll have to either patch xcb, or compile xlib without it for Fedora.

Revision history for this message
In , Wez (wez) wrote :

(In reply to comment #22)
> ABI compatibility is not a matter of black and white, but even if it were, it
> certainly is not defined by what's in Keith Packard's head.

No-one has suggested that it is. Quite the opposite, in fact.

> The whole *POINT* of an ABI is to keep applications working without
> recompiling them. And it's not a matter of "getting away with it with certain
> versions".

If you mean "bumping DLL version numbers doesn't mean you can change the behaviour of the DLL" then I'm afraid that's exactly what version numbers are for - so new applications can use the new behaviour and old ones can load a different version, or a shim to the new one, to get the behaviour they need.

> They worked with *all* versions until you broke them.

I'm not who you mean by "you", but I know *I* haven't "broken" Xlib, nor have the XCB developers - perhaps you meant to address the Fedora Core 8 distribution maintainers, who chose to distribute XCB Xlib in place of classic Xlib without considering the consequences for users with broken X apps?

Revision history for this message
Loom (loom) wrote :

This is not only a Java problem i.e. in drscheme there is the same error:
https://bugs.launchpad.net/bugs/172517

I know this, because I patched my java to not use Xinerama and since then no java "xcb_xlib_lock: Assertion"-errors.

So Java 7 is no solution, but libxcb has to be fixed.

Revision history for this message
Mikael Nilsson (mini) wrote : Re: [Bug 86103] Re: azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

On fre, 2007-12-07 at 15:15 +0000, Loom wrote:
> This is not only a Java problem i.e. in drscheme there is the same error:
> https://bugs.launchpad.net/bugs/172517
>
> I know this, because I patched my java to not use Xinerama and since
> then no java "xcb_xlib_lock: Assertion"-errors.
>
> So Java 7 is no solution, but libxcb has to be fixed.

It's an application threading bug, so I don't see how libxcb can solve
it.

Just because it appears in more than one place does not mean that the
library is at fault.

/Mikael

>
--
<email address hidden>

Plus ça change, plus c'est la même chose

Bug Watch Updater (bug-watch-updater)
Changed in xlibs:
status: Unknown → Invalid
Revision history for this message
Alexander Rødseth (alexanro) wrote :

For Hardy Heron:
This command works with Cgoban3 (the only Java-application I really use):
LIBXCB_ALLOW_SLOPPY_LOCK=true padsp javaws http://files.gokgs.com/javaBin/cgoban.jnlp

the "padsp" is needed to get sound if you have pulseaudio installed

Thanks for the LIBXCB_ALLOW_SLOPPY_LOCK=true tip further up here!

Revision history for this message
Che Guevara (che-guevara-3) wrote :

Marking invalid for icedtea since it's not an issue there

Changed in icedtea-java7:
status: New → Invalid
Revision history for this message
Antoine Pairet (b-ly) wrote :

Can someone check bug 185311, I think this is the same issue, but I don't know which to mark as duplicate.
Thanks

Revision history for this message
mattia.lambertini (mat-lambertini) wrote :

same bug for me on hardy. Azureus crash on start-up. I have installed azureus 2.5.0.4-1ubuntu3.
But it is not affect all the java application, eclipse run perfectly. This is the output on my shell when i try to launch azureus:

Looking for and picking a preferred Java runtime
Use environment AZUREUS_JAVA to override
Using Java: /usr/lib/jvm/java-6-sun/jre/bin/java
changeLocale: *Default Language* != English (United States). Searching without country..
changeLocale: Searching for language English in *any* country..
changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)'
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb45ed767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb45ed8b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb48c329d]
#3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xb35408ce]
#4 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xb351d067]
#5 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xb351d318]
#6 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0xb351d61f]
#7 [0xb5cb2e9d]
#8 [0xb5cabedd]
#9 [0xb5cabedd]
#10 [0xb5ca9249]
#11 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c40d]
#12 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x6310378]
#13 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c2a0]
#14 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so(JVM_DoPrivileged+0x363) [0x6272153]
#15 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7cc496d]
#16 [0xb5d95235]
#17 [0xb5cabd77]
#18 [0xb5ca9249]
#19 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/client/libjvm.so [0x621c40d]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

Revision history for this message
Matthew Wardrop (mister.wardrop) wrote :

There is a work around posted at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 .

QUOTE:
I worked with jcristau and christoph4 via IRC on #debian-x, and we managed to
track down the problem with broken locking in Sun Java 1.5 and 1.6. It only
occurs if Java finds the Xinerama extension, at which point it does something
broken with locking and triggers the assertion. If Java never finds the
Xinerama extension, it doesn't trigger the assertion for broken locking.

The following workarounds address this problem:

For sun-java5-bin:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/xawt/libmawt.so

For sun-java6-bin:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so

The same fix (applied to the appropriate file) might work for other
proprietary JDKs.

- Josh Triplett
END QUOTE.

It worked for me.

Kind Regards,
Matthew

Revision history for this message
Gabriel Ambuehl (gabriel-ambuehl) wrote : Re: [Bug 86103] Re: azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

For me, the following did work around the issue
echo "export LIBXCB_ALLOW_SLOPPY_LOCK=true" >> ~/.bash_profile

(looks less dangerous to me than patching binaries with sed :)

Revision history for this message
Christian Göbel (christiangoebel) wrote :

Just to complete the information on workarounds:
The workaround by Gabriel Ambuehl did not work for me (at least id did not work for the program Jedit (see bug #187061 ))
However the workaround by Matthew Wardrop did the job.

Could this type of workaround be added at the end of the installation script?

Revision history for this message
Juraj Lukac (hrasko) wrote :

Hi,
the same situation here. I could't run any java application until I applied the workaround by Matthew Wardrop. Although editing the libmawt.so file doesn't look like a systematic fix, it works and I can run java applications now.
I run Ubuntu 8.04 i386.

Thanks a lot Matthew ;)

Juraj

Revision history for this message
Juraj Lukac (hrasko) wrote :

I've forgotten: exporting LIBXCB_ALLOW_SLOPPY_LOCK variable didn't work for me.

Revision history for this message
Khorne (szczygiel-piotr) wrote :

Matthew's workaround works for me (thank you very much Matthew) but it doesn't fix everything. For example Netbeans works fine but I cannot open opera. It always throws output like this:

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb6b1a767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb6b1a8b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb728229d]
#3 /usr/lib/j2se/1.4/jre/lib/i386/libawt.so(XineramaIsActive+0xa5) [0xb7c237d5]
#4 /usr/lib/libqt-mt.so.3(_ZN14QDesktopWidget11resizeEventEP12QResizeEvent+0x20) [0xb759d1da]
#5 /usr/lib/libqt-mt.so.3(_ZN7QWidget5eventEP6QEvent+0x52b) [0xb769b2a3]
#6 /usr/lib/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x274) [0xb75f8c36]
#7 /usr/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xce8) [0xb75fb564]
#8 /usr/lib/libqt-mt.so.3(_ZN12QApplication9sendEventEP7QObjectP6QEvent+0x5b) [0xb7589279]
#9 /usr/lib/libqt-mt.so.3(_ZN12QApplication16sendPostedEventsEP7QObjecti+0x25c) [0xb75f9c6e]
#10 /usr/lib/libqt-mt.so.3(_ZN14QDesktopWidgetC1Ev+0x87) [0xb759ce61]
#11 /usr/lib/libqt-mt.so.3(_ZN12QApplication7desktopEv+0x5e) [0xb75f8e42]
#12 /usr/lib/libqt-mt.so.3(_ZN12QApplication9constructERiPPcNS_4TypeE+0xcc) [0xb7600296]
#13 /usr/lib/libqt-mt.so.3(_ZN12QApplicationC2ERiPPc+0x6a) [0xb7600670]
#14 /usr/lib/opera/9.26-20080218.6/opera [0x8648179]
#15 /usr/lib/opera/9.26-20080218.6/opera [0x8060cb2]
#16 /usr/lib/opera/9.26-20080218.6/opera(_ZN7QWidget6createEmbb+0x554) [0x805ec94]
#17 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7065450]
#18 /usr/lib/opera/9.26-20080218.6/opera(_ZNK7QDialog15minimumSizeHintEv+0x111) [0x805eb71]
opera: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

Revision history for this message
zivs (lopa-kungs) wrote :

All mentioned ways to fix the problem excludes Opera browser:

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb6b6e767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb6b6e8b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xb72ce29d]
#3 /usr/lib/j2se/1.4/jre/lib/i386/libawt.so(XineramaIsActive+0xa5) [0xb7c6f7d5]
#4 /usr/lib/libqt-mt.so.3(_ZN14QDesktopWidget11resizeEventEP12QResizeEvent+0x20) [0xb75e91da]
#5 /usr/lib/libqt-mt.so.3(_ZN7QWidget5eventEP6QEvent+0x52b) [0xb76e72a3]
#6 /usr/lib/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x274) [0xb7644c36]
#7 /usr/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xce8) [0xb7647564]
#8 /usr/lib/libqt-mt.so.3(_ZN12QApplication9sendEventEP7QObjectP6QEvent+0x5b) [0xb75d5279]
#9 /usr/lib/libqt-mt.so.3(_ZN12QApplication16sendPostedEventsEP7QObjecti+0x25c) [0xb7645c6e]
#10 /usr/lib/libqt-mt.so.3(_ZN14QDesktopWidgetC1Ev+0x87) [0xb75e8e61]
#11 /usr/lib/libqt-mt.so.3(_ZN12QApplication7desktopEv+0x5e) [0xb7644e42]
#12 /usr/lib/libqt-mt.so.3(_ZN12QApplication9constructERiPPcNS_4TypeE+0xcc) [0xb764c296]
#13 /usr/lib/libqt-mt.so.3(_ZN12QApplicationC2ERiPPc+0x6a) [0xb764c670]
#14 /usr/lib/opera/9.25-20071214.6/opera [0x8648079]
#15 /usr/lib/opera/9.25-20071214.6/opera [0x8060cb2]
#16 /usr/lib/opera/9.25-20071214.6/opera(_ZN7QWidget6createEmbb+0x554) [0x805ec94]
#17 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb70b9450]
#18 /usr/lib/opera/9.25-20071214.6/opera(_ZNK7QDialog15minimumSizeHintEv+0x111) [0x805eb71]
opera: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

Applied both set of workarounds:
sudo sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/libawt.so
sudo sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386/libawt.so
and
export LIBXCB_ALLOW_SLOPPY_LOCK=true

and still get:

ken@neptune:~/BGBlitz$ ./bgblitz.sh
JAVA = java
JVM_OPTS = -Xmx128m -server
HOME = /home/ken/BGBlitz
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xa8303767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xa83038b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xa7f5829d]
#3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xa833f8ce]
#4 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xa831c067]
#5 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xa831c318]
#6 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0xa831c61f]
#7 [0xb4ce23aa]
#8 [0xb4cdaf0d]
#9 [0xb4cdaf0d]
#10 [0xb4cd8249]
#11 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d]
#12 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x64fd168]
#13 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x6373220]
#14 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so(JVM_DoPrivileged+0x363) [0x63c90d3]
#15 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7cf396d]
#16 [0xb4ce23aa]
#17 [0xb4cdada7]
#18 [0xb4cd8249]
#19 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x78c05767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0x78c058b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x7875a29d]
#3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x7885a8ce]
#4 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x78837067]
#5 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x78837318]
#6 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0x7883761f]
#7 [0xb4ccb3aa]
#8 [0xb4cc3f0d]
#9 [0xb4cc3f0d]
#10 [0xb4cc1249]
#11 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d]
#12 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x64fd168]
#13 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x6373220]
#14 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so(JVM_DoPrivileged+0x363) [0x63c90d3]
#15 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7cdc96d]
#16 [0xb4ccb3aa]
#17 [0xb4cc3da7]
#18 [0xb4cc1249]
#19 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

Revision history for this message
Sascha Grossenbacher (berdir) wrote :

there are multiple libmawt.so files, and opera and this bgblitz tool are using different ones...

sudo sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386/libawt.so

bgblitz:
#3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xa833f8ce]

opera:
#3 /usr/lib/j2se/1.4/jre/lib/i386/libawt.so(XineramaIsActive+0xa5) [0xb7c6f7d5]

So, look for the last used libawt.so/libmawt.so and patch it with sed

sudo sed -i 's/XINERAMA/FAKEEXTN/g' <insert path>

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

Berdir wrote:
> there are multiple libmawt.so files, and opera and this bgblitz tool are
> using different ones...
>
> sudo sed -i 's/XINERAMA/FAKEEXTN/g'
> /usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386/libawt.so
>
> bgblitz:
> #3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xa833f8ce]
>
> opera:
> #3 /usr/lib/j2se/1.4/jre/lib/i386/libawt.so(XineramaIsActive+0xa5) [0xb7c6f7d5]
>
> So, look for the last used libawt.so/libmawt.so and patch it with sed
>
> sudo sed -i 's/XINERAMA/FAKEEXTN/g' <insert path>

Those two were the only ones on my system.

...Ken

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

Kenneth Loafman wrote:
> Berdir wrote:
>> there are multiple libmawt.so files, and opera and this bgblitz tool are
>> using different ones...
>>
>> sudo sed -i 's/XINERAMA/FAKEEXTN/g'
>> /usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386/libawt.so
>>
>> bgblitz:
>> #3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0xa833f8ce]
>>
>> opera:
>> #3 /usr/lib/j2se/1.4/jre/lib/i386/libawt.so(XineramaIsActive+0xa5) [0xb7c6f7d5]
>>
>> So, look for the last used libawt.so/libmawt.so and patch it with sed
>>
>> sudo sed -i 's/XINERAMA/FAKEEXTN/g' <insert path>
>
> Those two were the only ones on my system.

Whoops, spoke too soon. Did not see libmawt.so in the list. Found 6 of
those and patched. BGBlitz works now under Hardy.

...Thanks,
...Ken

Revision history for this message
sonmez (sonmezsahut) wrote :

I am trying to install Maple and i get a very similar error.
I have Hardy with kernel 2.6.24-8 generic, java version "1.6.0_04"

Here is the error I get.

$ sudo sh installMapleLinuxSU
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
nawk: cmd. line:6: warning: escape sequence `\.' treated as plain `.'

Launching installer...

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb7fba767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7fba8b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0xabe0829d]
#3 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/libawt.so(XineramaQueryScreens+0xd0) [0xac0b2688]
#4 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/libawt.so(xineramaInit+0x6f) [0xac06c0a7]
#5 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/libawt.so(awt_init_Display+0x1af) [0xac06c37b]
#6 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/libawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x1d) [0xac06c5a5]
#7 [0xb3c0afe4]
#8 [0xb3c04ddb]
#9 [0xb3c02104]
#10 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7bcab44]
#11 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7c7ea6d]
#12 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7bcad96]
#13 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7baff6f]
#14 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7bb469c]
#15 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7baf1cb]
#16 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7bb49af]
#17 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so [0xb7c2b538]
#18 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/client/libjvm.so(JVM_FindClassFromClassLoader+0x208) [0xb7c1a800]
#19 /tmp/install.dir.7529/Linux/resource/jre/lib/i386/libjava.so(Java_java_lang_Class_forName0+0x182) [0xb798f97e]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

Revision history for this message
Sascha Grossenbacher (berdir) wrote :

Ok, that one is a bit complexer, because the installer does unpack its own version.

Perhabs someone does know a better way, but I think, you need to fix the libawt.so on the fly between "Unpacking the JRE..." and "Launching installer.."

1. Prepare two shells, on for the installer, one for the sed command

2. Save the following lines to a bash script (for exampe fixJava.sh)

#!/bin/bash

for file in `find /tmp -name "*awt.so"`; do
 echo $file
 sudo sed -i 's/XINERAMA/FAKEEXTN/g' $file
done

3. make that file executable: chmod u+x <filename>

4. enter the name of the file, but don't start it.. ./fixJava.sh

5. in the other shell, start the Maple Installer

6. Wait for the Line "Extracting the installation resources from the installer archive...", then start the fixJava.sh script

7. Install Maple ;)

PS: the script should work for the normal java installation too.. just change /tmp to /usr/lib/jvm and call it with sudo

Revision history for this message
Matti Lindell (mlind) wrote :

This bug is related to bug #87947. Sloppy locks are probably going to be re-enabled for Hardy like it was with Gutsy, so that Java5&6 JVM's unbreak.

Matti Lindell (mlind)
Changed in sun-java6:
importance: Undecided → High
Daniel Hahler (blueyed)
Changed in sun-java6:
milestone: none → ubuntu-8.04-beta
Changed in sun-java5:
milestone: none → ubuntu-8.04-beta
Revision history for this message
zivs (lopa-kungs) wrote :

Thanks Berdir!
Following line helped for Opera (on Ubuntu 8.04 Alpha) :
sudo sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/j2se/1.4/jre/lib/i386/libawt.so

Daniel Hahler (blueyed)
Changed in sun-java6:
status: Confirmed → Triaged
Changed in sun-java5:
status: Confirmed → Triaged
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Sun won't fix the old java's, so we've worked around it in libxcb, see bug 87947.

Changed in sun-java6:
status: Triaged → Won't Fix
Changed in sun-java5:
status: Triaged → Won't Fix
Revision history for this message
Matthias Klose (doko) wrote :

reopening

Changed in sun-java5:
status: Won't Fix → Confirmed
Changed in sun-java6:
status: Won't Fix → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

Since this has been worked around in libxcb for Hardy, this bug no longer needs to be beta-critical. However, it should remain open as it is still a bug in Java.

Changed in sun-java5:
milestone: ubuntu-8.04-beta → none
Changed in sun-java6:
milestone: ubuntu-8.04-beta → none
Revision history for this message
Jamey Sharp (sharpone) wrote :

Josh and I just proposed a set of changes to XCB and Xlib/XCB which,
among other things, should address all the outstanding assertion
failures and synchronization problems that we know of. Could anyone
experiencing this bug please build XCB and Xlib with the patches found
at http://lists.freedesktop.org/archives/xcb/2008-March/003347.html and
retest?

Revision history for this message
exactt (giesbert) wrote :

testing here with latest hardy on x86_64 and i get the following error when starting tomcat from within eclipse:

Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f06d101a97c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f06d101aa84]
#2 /usr/lib/libX11.so.6(_XReply+0x10f) [0x7f06d1873f4f]
#3 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f06d1d8a786]
#4 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f06d1d6b4eb]
#5 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f06d1d6b7bd]
#6 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x12) [0x7f06d1d6ba32]
#7 [0x7f071723e878]
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f06d101a97c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x15) [0x7f06d101aa15]
#2 /usr/lib/libX11.so.6 [0x7f06d1873323]
#3 /usr/lib/libX11.so.6(XGetVisualInfo+0x2c) [0x7f06d186a72c]
#4 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f06d1d6a885]
#5 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f06d1d6aad9]
#6 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so [0x7f06d1d6b85f]
#7 /usr/lib/jvm/java-6-sun-1.6.0.05/jre/lib/amd64/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x12) [0x7f06d1d6ba32]
#8 [0x7f071723e878]

Revision history for this message
mikerin.slava@gmail.com (mikerin-slava) wrote :

re:
 Josh and I just proposed a set of changes to XCB and Xlib/XCB which,
among other things, should address all the outstanding assertion
failures and synchronization problems that we know of. Could anyone
experiencing this bug please build XCB and Xlib with the patches found
at http://lists.freedesktop.org/archives/xcb/2008-March/003347.html and
retest?

----------
Josh can you or anyone else please post instructions on building xcb and xlib with these patches. I looked at the link, but it is not clear to me what has to be done. I am bit of a newbee.
 I need to solve this problem, but I do not know how to build these libs and none of the proposed workarounds work for me.
thanks

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sun-java6 - 6-06-0ubuntu1

---------------
sun-java6 (6-06-0ubuntu1) hardy; urgency=low

  * New upstream bug fix release.
    - Release notes at http://java.sun.com/javase/6/webnotes/ReleaseNotes.html.
    - Fixes Xlib/XCB locking problems. LP: #86103. Closes: #414535.
    - Update timezone information. Closes: #468234.
  * Don't open the control panel when starting a WebStart application.
    LP: #84501.
  * javaws.desktop: Add `%u' to the Exec key, remove -viewer option.
    Closes: #436645.
  * Suggest ttf-wqy-zenhei instead of ttf-arphic-uming (only available in .ttc
    format not supported by Sun Java) (Arne Goetje). LP: #213925.
  * Only use the basename for icons in desktop files. LP: #207413.
  * Add XS-Autobuild: yes attribute. Closes: #473164.
  * ia32-sun-java6-bin: Recommend lib32nss-mdns on amd64. Closes: #430917.
  * JB-bin.postinst.in: Call java -client -Xshare:dump with -Xmx1m, if the
    memory is available. Closes: #425654, #428654.
  * binfmt-support: Handle /usr/share/binfmts/jar as a slave symlink of
    the jexec alternative, install the binfmt file in the jre libdir.
    Use the jexec alternative in the binfmt file.
  * Don't fail on removal, if /var/lib/binfmts/openjdk-6 is missing.
    Closes: #441880.
  * README.Debian: Clarify about configuring the ControlPanel. Closes: #459435.
  * Don't include empty directories in /usr/share. Closes: #472995.

 -- Matthias Klose <email address hidden> Wed, 16 Apr 2008 01:02:07 +0200

Changed in sun-java6:
status: Confirmed → Fix Released
Revision history for this message
mikerin.slava@gmail.com (mikerin-slava) wrote :

i just upgraded to sun-java6 - 6-06-0ubuntu1

dpkg -l sun-java6*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii sun-java6-bin 6-06-0ubuntu1 Sun Java(TM) Runtime Environment (JRE) 6 (ar
un sun-java6-font <none> (no description available)
ii sun-java6-jre 6-06-0ubuntu1 Sun Java(TM) Runtime Environment (JRE) 6 (ar
ii sun-java6-plug 6-06-0ubuntu1 The Java(TM) Plug-in, Java SE 6

and tried installing a java application

sh VP_Suite_Linux_3_2_sp1_20080311.sh
Unpacking JRE ...
Preparing JRE ...
Starting Installer ...
Locking assertion failure. Backtrace:
#0 /usr/local/lib/libxcb-xlib.so.0 [0xb7371767]
#1 /usr/local/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb73718b1]
#2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x7cdd01bd]
#3 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/xawt/libmawt.so [0x7cec0d7e]
#4 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/xawt/libmawt.so [0x7ceaad47]
#5 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/xawt/libmawt.so [0x7ceaaec3]
#6 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x26) [0x7ceab106]
#7 [0xb178d008]
#8 [0xb1786b6b]
#9 [0xb1786b6b]
#10 [0xb1784236]
#11 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/server/libjvm.so [0xb760cd7c]
#12 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/server/libjvm.so [0xb77dc618]
#13 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/server/libjvm.so [0xb760cbaf]
#14 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/server/libjvm.so(JVM_DoPrivileged+0x32d) [0xb766a6bd]
#15 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb731430d]
#16 [0xb178c898]
#17 [0xb1786a94]
#18 [0xb1784236]
#19 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/server/libjvm.so [0xb760cd7c]
java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted (core dumped)

still not working.. :(

Revision history for this message
Matthias Klose (doko) wrote :

<email address hidden> schrieb:
> i just upgraded to sun-java6 - 6-06-0ubuntu1
> Starting Installer ...
> Locking assertion failure. Backtrace:
> #0 /usr/local/lib/libxcb-xlib.so.0 [0xb7371767]
> #1 /usr/local/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb73718b1]
> #2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x7cdd01bd]
> #3 /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/xawt/libmawt.so [0x7cec0d7e]
>
> still not working.. :(

yes, because you're using your own VM installed in /home/slava/dev/tools

Revision history for this message
mikerin.slava@gmail.com (mikerin-slava) wrote :
  • unnamed Edit (3.4 KiB, text/html; charset=ISO-8859-1)

it is a vm packaged as part of the installation file... it seems like a self
extracting binary archive. i tried to extract it with with no success. I
guess I should be contacting the manufacturer of the file... any other
ideas? thank you

On Thu, Apr 17, 2008 at 1:20 PM, Matthias Klose <email address hidden> wrote:

> <email address hidden> schrieb:
> > i just upgraded to sun-java6 - 6-06-0ubuntu1
> > Starting Installer ...
> > Locking assertion failure. Backtrace:
> > #0 /usr/local/lib/libxcb-xlib.so.0 [0xb7371767]
> > #1 /usr/local/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb73718b1]
> > #2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x7cdd01bd]
> > #3
> /home/slava/dev/tools/eclipse/archive/VP_Suite_Linux_3_2_sp1_20080311.sh.11880.dir/jre/lib/i386/xawt/libmawt.so
> [0x7cec0d7e]
> >
> > still not working.. :(
>
> yes, because you're using your own VM installed in /home/slava/dev/tools
>
> --
> azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock'
> failed.
> https://bugs.launchpad.net/bugs/86103
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Sun Java SE Development Kit: Confirmed
> Status in Modular X11 Libraries: Invalid
> Status in Source Package "icedtea-java7" in Ubuntu: Invalid
> Status in Source Package "sun-java5" in Ubuntu: Confirmed
> Status in Source Package "sun-java6" in Ubuntu: Fix Released
> Status in Source Package "sun-java5" in Debian GNU/Linux: Confirmed
>
> Bug description:
> Azureus crashes with both sun-java5 and sun-java6
>
> This error came from azureus and sun-java5, when it started a download:
>
> Starting Azureus...
> Java exec found in PATH. Verifying...
> Suitable java version found [java = 1.5.0_11]
> Configuring environment...
> Loading Azureus:
> java -Xms16m -Xmx128m -cp "/opt/azureus/Azureus2.jar:/opt/azureus/swt.jar"
> -Djava.library.path="/opt/azureus" -Dazureus.install.path="/opt/azureus"
> org.gudy.azureus2.ui.swt.Main ''
>
> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
> ./azureus: line 112: 32551 Aborted (core dumped)
> ${JAVA_PROGRAM_DIR}java -Xms16m -Xmx128m -cp "${CLASSPATH}"
> -Djava.library.path="${PROGRAM_DIR}" -Dazureus.install.path="${PROGRAM_DIR}"
> org.gudy.azureus2.ui.swt.Main "$@"
> Azureus TERMINATED.
>
>
> And with sun-java6 again:
>
> ./azureus: line 112: 20574 Aborted (core dumped)
> ${JAVA_PROGRAM_DIR}java -Xms16m -Xmx128m -cp "${CLASSPATH}"
> -Djava.library.path="${PROGRAM_DIR}" -Dazureus.install.path="${PROGRAM_DIR}"
> org.gudy.azureus2.ui.swt.Main "$@"
> Azureus TERMINATED.
>
>
> with java-gcj everything works out OK
>

Marco Vittorini Orgeas (marcovorg)
description: updated
description: updated
Revision history for this message
robogeek (david-herron-sun) wrote :

I just tested this with java-1.5.0-sun, java-6-sun and java-6-openjdk. Azureus works with all three.

Because the /usr/bin/azureus script doesn't honor the java alternative setting (it hardcodes several paths in the script) you have to be careful to run it like so:-

% export AZUREUS_JAVA=/usr/lib/jvm/JAVA/jre/bin/java
% azureus

And you also have to be careful to exit the old Azureus process each time you relaunch the app. Doing so it runs with all three implementations.

Changed in sun-java5:
status: Confirmed → Fix Released
Didier Roche-Tolomelli (didrocks)
Changed in icedtea-java7:
assignee: nobody → didrocks
assignee: didrocks → nobody
Bug Watch Updater (bug-watch-updater)
Changed in sun-java:
status: Confirmed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in sun-java5:
status: Confirmed → Fix Released
Timo Jyrinki (timo-jyrinki)
Changed in jabref:
status: New → Invalid
Bug Watch Updater (bug-watch-updater)
Changed in xlibs:
importance: Unknown → Critical
status: Invalid → Won't Fix
Bug Watch Updater (bug-watch-updater)
Changed in xlibs:
importance: Critical → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in xlibs:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.