| Summary: | <dev-java/sun-jdk-1.6.0.06 and <dev-java/sun-jre-bin-1.6.0.06 do not work if libX11 is compiled with USE="xcb" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
| Component: | [OLD] Development | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | albzey, alex, blog, casta, cgibreak, depontius, ellingsw+20942, flexx, frederic.heulin, gentoo-bug, gentoo-bugzilla, gentoo, gimpel, guillaume.ramelet, jstepien, kevin.bowling, kyron, levertond, luminoso, m.debruijne, marek, matrixhax0r, mmokrejs, mr.ddc, n-roeser, no.hope, parmigio, plaes, rb6, rhill, thomas.jaeger, x11, zlin |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174434 | ||
| Attachments: | Java VM crash log | ||
|
Description
Petteri Räty (RETIRED)
2006-11-26 14:27:18 UTC
this is a sun java problem. As reported here: http://www.debian-news.net/modules/news/article.php?storyid=1782 this bug should be posted to Sun bug tracking I've found a similar problem adding xcb feature to libX11 and mesa, and rebuild xfce4 from SVN, but looks like is a libXcomposite bug just fixed: http://comments.gmane.org/gmane.comp.desktop.xfce.devel.version4/12406 Good luck! Hi, this looks to be a libXrandr thing: http://lists.freedesktop.org/archives/xcb/2007-January/002523.html The patch is available here: http://gitweb.freedesktop.org/?p=xorg/lib/libXrandr.git;a=blobdiff;h=778422747ddaa16324bd90a31134eb1c7abd852c;hp=577ccd653aa02933e570c66cd6eadd501e739db3;hb=36a4a633a93a89bd854f49e670777925c9751de3;f=src/XrrConfig.c Didn't see any mention of java in those links. As for the libs, the only one mentioned in the debian bug that sun-jdk depends on directly is libXi (didn't check for indirect deps), so maybe that's it? What happened was that I was trying to use LWJGL on with XCB enabled and I got this weird problem. For some reason, none of my other java apps had this issue, so I assumed it was due to LWJGL and I posted in their forums about it. One of their developers (Elias Naur) was nice enough to spend some time and track down where the issue really came from. http://lwjgl.org/forum/index.php/topic,2168.0.html Oh, the libXrandr patch by itself does not seem to be enough. Maybe just patch out the assertion for now? According to this: https://bugs.freedesktop.org/show_bug.cgi?id=8926 A fix in libX11 was committed on Nov. 11 but libX11-1.1.1 was released on Nov. 30 and some people still have bugs? Yep, this definetely still occurs with an up to date (well as-of 20070225) ~x86 system. Easly reproducable by invoking appletviewer. Hmm, I just gave up and patched out the assertion. It makes the locking pointless, but at least things work now. Created attachment 113215 [details]
Java VM crash log
Some more information.. hopefully someone will be able to extract the required data.
Here is a work around that works on 1.4: https://bugs.freedesktop.org/show_bug.cgi?id=9336#c13 (In reply to comment #0) > java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed. > > Probably the same problem is also in 1.4 so we should add some built_with_use > tests to the ebuilds. I have not tested with 1.6 yet and don't have the time to > do it today any way as I need to get up early tomorrow morning for the army. > I found this bug under different circumstances, and have done a little searching on it. Apparently xcb has "tightened up" the locking over what Xlib did, and it shows up all over the place. Sun's JVM is merely one spot. For the 2 I've personally run into there's also Cadence IC Craftsman 6.1, and one of the collection of programs in xfce-4.4. (Apparently whatever displays the wallpaper, because that's what's broken.) There is a patch midway down the page here: http://planet.gentoo.org/developers/betelgeuse/2006/11/26/do_not_turn_on_the_xcb_use_flag_if_you_p_5 referenced by "Brian [Visitor]" that relaxes xcb locking semantics to match what Xlib did. While technically not correct, it does allow old code to run, including closed-source code like Cadence ICC-6.1. The patch is also controlled by an environment variable, so it's possible to turn on the loose locking on an as-needed basis, and leave things tight, otherwise. I would suggest including this patch as an option. I do not exactly know is this patch [1] is good or not, but it solves the crash with sun-jdk-1.6. A good thing to apply this to libxcb ? [1] http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11-libs/libxcb/xcb_xlib-no-assert-on-lock.patch (In reply to comment #12) > I do not exactly know is this patch [1] is good or not, but it solves the crash > with sun-jdk-1.6. > A good thing to apply this to libxcb ? > > [1] > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11-libs/libxcb/xcb_xlib-no-assert-on-lock.patch > Technically no, practically yes. This patch allows the locking to be "sloppy", as does the patch I referenced. The difference is that the patch I referenced makes locking sloppy only when an environment variable is set, whereas this patch allows locking to be sloppy all of the time. Without some sort of patch, xcb is essentially useless, because there is just too much "broken" software out there. I'm trying to run with "+xcb" in /etc/make.conf, and have so far set "-xcb" in /etc/portage/package.use for libX11 and mesa, hoping to pick up some of the benefits. This is a problem on EVERY system I maintain, so far. "Fix the client" is obviously the right answer, but equally obviously it's going to take time. Within that time, without a patch, xcb is a non-starter for ordinary usage. CCing x11 for advice... maybe you would include that patch via some "unsafe-locking" flag? (In reply to comment #14) > CCing x11 for advice... maybe you would include that patch via some > "unsafe-locking" flag? > I was thinking more in terms of keeping safe locking on by default. Then bad apps could be wrapped in a script, or existing wrappers could be tweaked to add the "unsafe locking" flag. BTW, there's another fix available for this, though it's the "universally unsafe" form: In "/etc/portage/env/x11-libs/libxcb-1.0" I have 'CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe -DNDEBUG"' and that (the "-DNDEBUG") seems to solve the problem. At least it allows Cadence IC6.1.1 to run. But it means I've given up all the enhanced locking safety checking of xcb. Hopefully a new release of libxcb will fix this, and my tweak will fade silently into the night. (In reply to comment #14) > CCing x11 for advice... maybe you would include that patch via some > "unsafe-locking" flag? > Distributions have been asked to specifically not do this by upstream. Most client bugs have been fixed. The upstream bug is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373. If anyone's willing to provide Sun with a stacktrace, they would really appreciate it. (In reply to comment #10) > Here is a work around that works on 1.4: > https://bugs.freedesktop.org/show_bug.cgi?id=9336#c13 > It really works for jdk-1.4, wouldn't putting a use flag in jdk1.4 specifying to use system xinerama an "acceptable" workaround? basically i've put "LD_PRELOAD=/usr/lib/libXinerama.so" in my .profile but i think a wrapper script for jdk1.4 would be enough If that fixed jdk1.4 are we maybe only missing some other embedded X library in the jdk 1.5 and 1.6? Here's a workaround from in the sun bug. It works for me with dev-java/sun-jdk-1.5.0.11. 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 You're welcome to try the libxcb ebuild from: http://bugs.gentoo.org/show_bug.cgi?id=176839#c1 Somewhat ugly, but best way I could see of solving the problem until clients are updated for the new xcb locking. (In reply to comment #18) > > 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 > Don't know what Sun thinks about modifying their proprietary stuff like this. Maybe we could add a xcb use flag for this. (In reply to comment #20) > Don't know what Sun thinks about modifying their proprietary stuff like this. > Maybe we could add a xcb use flag for this. What's the license say? Please test with the following patch: http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commitdiff_plain;h=c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8;hp=65f0ab5d46d80d55fc04d4eb14fa05f130eb8b9c That patch is for libX11-1.1.2 (In reply to comment #22) > Please test with the following patch: > > http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commitdiff_plain;h=c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8;hp=65f0ab5d46d80d55fc04d4eb14fa05f130eb8b9c > Doesn't seem to fix it here. pena libX11-1.1.2 # patch -p1 < /home/betelgeuse/patches/git-c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8.patch patching file modules/im/ximcp/imDefLkup.c <compile> betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.6" jarwizard java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed. Aborted betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.5" jarwizard java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed. Aborted Found this in the Sun bug at $URL: well, it looks like everyone believe that the cause of the problem is old version of Xinerama we use. We have updated it in 7.0 and so the problem must not be reproducible with latest builds of jdk 7. Since I can not check this (I have no environment for this :( It would be nice to get confirmation from the comunity. Posted Date : 2007-06-04 08:53:46.0 So betelgeuse, what does openjdk do :) (In reply to comment #25) > Found this in the Sun bug at $URL: > > well, it looks like everyone believe that the cause of the problem is old > version of > Xinerama we use. We have updated it in 7.0 and so the problem must not be > reproducible > with latest builds of jdk 7. > The problem is a static copy of libXinerama being linked in. It will not be solved as long as Sun is building their binaries on some old machine unless they manually update the libXinerama copy there. So there are no problems with OpenJDK as it builds against a Gentoo installed copy of libXinerama. (In reply to comment #26) > The problem is a static copy of libXinerama being linked in. It will not be > solved as long as Sun is building their binaries on some old machine unless > they manually update the libXinerama copy there. Well they said they updated it for jdk7 builds so might be worth trying out and reporting back so that they can do the same for 4/5/6 (hopefully at least 6...). Probably current jdk7 b13 isn't fixed yet because it's older than that comment... *** Bug 182444 has been marked as a duplicate of this bug. *** (In reply to comment #27) > Well they said they updated it for jdk7 builds so might be worth trying out and > reporting back so that they can do the same for 4/5/6 (hopefully at least > 6...). Probably current jdk7 b13 isn't fixed yet because it's older than that > comment... sun-jdk-1.7.0.0_alpha14 is in java-overlay, dated well after the comment on upstream bug, so it should be fixed. can anyone test and report? (In reply to comment #29) > > sun-jdk-1.7.0.0_alpha14 is in java-overlay, dated well after the comment on > upstream bug, so it should be fixed. can anyone test and report? > betelgeuse@pena ~ $ JAVA_LAUNCHER_DEBUG=1 GENTOO_VM="sun-jdk-1.7" java -version java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b14) Java HotSpot(TM) Tiered VM (build 1.7.0-ea-b14, mixed mode) betelgeuse@pena ~ $ JAVA_LAUNCHER_DEBUG=1 GENTOO_VM="sun-jdk-1.7" jarwizard java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed. Aborted It's not. Would be good to post that to upstream bug, and also that openjdk built against xinerama version x.y works fine (IIRC you said that). Parts of a discussion in #openjdk:
13:12 < Betelgeuse> tmarble: What is your stance on applying the sed fix in the ebuilds?
13:12 < tmarble> until that's done what we've agreed on with the Debian X maintainer is that the new X which enforces the new behavior will ship with the binary editor hack to avoid the problem (since we
cannot get this fixed for older releases -- in time) and yet it must work with xcb
13:12 < Betelgeuse> tmarble: At least it's not something that has passed the TCK any more then.
13:13 < Betelgeuse> tmarble: So Debian will go with the sed?
13:14 < tmarble> right -- and the rationale is that Debian will not be *distributing* the hacked binary (which would violate the DLJ), but individuals can apply the fix
13:15 < Betelgeuse> yeah we are not either
13:16 < Betelgeuse> tmarble: I can add a xcb use flag for it so it's optional
13:16 < Betelgeuse> tmarble: You need xcb use flag turned on in the first place to hit it
13:17 < Betelgeuse> tmarble: And then and einfo message that the binary is modified and as such not passed the TCK
13:17 < Betelgeuse> tmarble: Does that sound prudent?
13:18 < tmarble> well, my lack of experience with gentoo is a little challenging here...
Sun developer on Sun upstream bug now believes it's problem of X libraries and filled a bug there, closing Sun's bug. I'm changing URL of this bug accordingly. Disable "xcb" use flag. emerge --newuse world Problem solved. (In reply to comment #34) > Disable "xcb" use flag. > > emerge --newuse world > > Problem solved. workaround != solution The X team has marked this as NOTOURBUG again, since Sun is improperly linking some libs. Sun has reopened their bug and is in progress below: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 *** Bug 189773 has been marked as a duplicate of this bug. *** *** Bug 191810 has been marked as a duplicate of this bug. *** *** Bug 192118 has been marked as a duplicate of this bug. *** *** Bug 193184 has been marked as a duplicate of this bug. *** The best "fix" so far seems to be to add LIBXCB_ALLOW_SLOPPY_LOCK=1 to the java wrappers. Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510 (In reply to comment #41) > The best "fix" so far seems to be to add > > LIBXCB_ALLOW_SLOPPY_LOCK=1 > > to the java wrappers. > > Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510 > According to the upstream bug (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373), it is now Closed/Fixed with version 7(b22). I don't know if this changes the status of this bug at all though. I'm pretty new to bug tracking systems. =) So, I'll leave that to the more knowledgeable. (In reply to comment #42) > (In reply to comment #41) > > The best "fix" so far seems to be to add > > > > LIBXCB_ALLOW_SLOPPY_LOCK=1 > > > > to the java wrappers. > > > > Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510 > > > > According to the upstream bug > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373), it is now > Closed/Fixed with version 7(b22). I don't know if this changes the status of > this bug at all though. I'm pretty new to bug tracking systems. =) So, I'll > leave that to the more knowledgeable. > Until it hits our tree, this is still a valid bug. (In reply to comment #41) > The best "fix" so far seems to be to add > > LIBXCB_ALLOW_SLOPPY_LOCK=1 > > to the java wrappers. > > Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510 > How? I tried export LIBXCB_ALLOW_SLOPPY_LOCK=1 then run simple javaws, same error: ~/Desktop $ export LIBXCB_ALLOW_SLOPPY_LOCK=1 ~/Desktop $ javaws -viewer ~/Desktop $ java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed. You need libxcb 1.1 (or a personally patched 1.0) for that to work. *** Bug 199074 has been marked as a duplicate of this bug. *** Is there any workaround for this bug. I cannot use netbeans or eclipse . Yes, install libxcb 1.1 and set LIBXCB_ALLOW_SLOPPY_LOCK=1 in your environment. Sun has marked as closed, but the version annonced to be working is 7(b22). So, this mean that we have to move to Java 7 (?) to get a working java on our Compiz-fusion xcb enabled PC ? > So, this mean that we have to move to Java 7 (?) to get a working java on our > Compiz-fusion xcb enabled PC ? That, or see comment 49 (In reply to comment #48) > Yes, install libxcb 1.1 and set LIBXCB_ALLOW_SLOPPY_LOCK=1 in your environment. How bout we add this to run-java-tool (conditionally with xcb flag in java-config, which would also pull >=libxcb-1.1)? Or we can even do some generic "run-java-toolrc" sourcing (in /etc and $HOME) and xcb flag would install this rc file with the variable in /etc. (In reply to comment #51) > (In reply to comment #48) > > Yes, install libxcb 1.1 and set LIBXCB_ALLOW_SLOPPY_LOCK=1 in your environment. > > How bout we add this to run-java-tool (conditionally with xcb flag in > java-config, which would also pull >=libxcb-1.1)? > Or we can even do some generic "run-java-toolrc" sourcing (in /etc and $HOME) > and xcb flag would install this rc file with the variable in /etc. > An elog describing the process in pkg_postinst(), or probably more usefully, a pkg_config() that adds a file with the export to /etc/env.d would be the most sensible solution IMO, it should not be enabled without user interaction since the sloppy locking is a hack at best. (In reply to comment #52) > An elog describing the process in pkg_postinst(), or probably more usefully, a > pkg_config() that adds a file with the export to /etc/env.d would be the most > sensible solution IMO, it should not be enabled without user interaction since > the sloppy locking is a hack at best. Something like this, which is already in libxcb-1.1? pkg_postinst() { x-modular_pkg_postinst elog "libxcb-1.1 adds the LIBXCB_ALLOW_SLOPPY_LOCK variable to allow" elog "broken applications to keep running instead of being aborted." elog "Set this variable if you need to use broken packages such as Java" elog "(for example, add LIBXCB_ALLOW_SLOPPY_LOCK=1 to /etc/env.d/00local" elog "and run env-update)." } > Something like this, which is already in libxcb-1.1?
Yeah, I'm assuming people don't read it, because they still come and CC on this bug :) Therefore an out-of-the box workaround seems like a good idea to me.
(In reply to comment #53) > > Something like this, which is already in libxcb-1.1? > > pkg_postinst() { > x-modular_pkg_postinst > > elog "libxcb-1.1 adds the LIBXCB_ALLOW_SLOPPY_LOCK variable to allow" > elog "broken applications to keep running instead of being aborted." > elog "Set this variable if you need to use broken packages such as Java" > elog "(for example, add LIBXCB_ALLOW_SLOPPY_LOCK=1 to /etc/env.d/00local" > elog "and run env-update)." > } > Hehe, yes something like that - basically what I wrote in #176839 but more sensical ;) If people can't read, well... *** Bug 204345 has been marked as a duplicate of this bug. *** *** Bug 209838 has been marked as a duplicate of this bug. *** sun-jdk and sun-jre-bin fixed in 1.6.0.06 just commited to CVS I will leave this open until we get it stable, and should think where to document that people with xcb should run 1.6 and not 1.5 (which I doubt they will fix...) Confirming this got fixed in 1.6.0.06. Please stabilise in few days. Seems the problem is still present. I get the problem when I try to enable the OpenGL interface within the program (could it be spawning another process without carrying over the LIBXCB_ALLOW_SLOPPY_LOCK=1 var?...I'll ask.
kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/K-Means/BLAS_test $ eselect java-vm list
Available Java Virtual Machines:
[1] blackdown-jdk-1.4.2
[2] emul-linux-x86-java-1.5
[3] emul-linux-x86-java-1.6
[4] icedtea
[5] icedtea-6
[6] sun-jdk-1.5
[7] sun-jdk-1.6
[8] sun-jre-bin-1.5
[9] sun-jre-bin-1.6 system-vm user-vm
kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/K-Means/BLAS_test $ LIBXCB_ALLOW_SLOPPY_LOCK=1 paraprof
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
/home/kyron/TAU/TAU/x86_64/bin/paraprof: line 88: 8334 Aborted java -Xmx800m -Dderby.system.home=${LIBDIR} -Dpython.verbose=error -Djava.library.path=${LIBDIR} -cp ${JARS} ${APPLE_OPTIONS} edu/uoregon/tau/paraprof/ParaProf ${PPROFOPT} $*
kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/K-Means/BLAS_test $
Try explicitly exporting/setting the variable in a separate command from running your program. Also make sure you're actually on libxcb 1.1, which is ~arch. (In reply to comment #60) > Seems the problem is still present. I get the problem when I try to enable the > OpenGL interface within the program (could it be spawning another process > without carrying over the LIBXCB_ALLOW_SLOPPY_LOCK=1 var?...I'll ask. > You shouldn't even need the sloppy lock if you are running with 1.6. (In reply to comment #61) > Also make sure you're actually on libxcb 1.1 Yup, that did it. Also, as per Comment #62, I need not the exported variable. I now only get the following failure in the command line without loosing my app: Locking assertion failure. Backtrace: #0 /usr/lib/libxcb-xlib.so.0 [0x7f1705d5ca1c] #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f1705d5cac4] #2 /usr/lib/libX11.so.6(_XReply+0x260) [0x7f17061afbe0] #3 /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(XineramaQueryScreens+0xd7) [0x7f1707726167] #4 /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(xineramaInit+0x4b) [0x7f17076ed88b] #5 /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(awt_init_Display+0xfd) [0x7f17076ed9fd] #6 /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x9) [0x7f17076edb99] #7 [0x7f174348ff80] (In reply to comment #63) > #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f1705d5cac4] > #2 /usr/lib/libX11.so.6(_XReply+0x260) [0x7f17061afbe0] > #3 > /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(XineramaQueryScreens+0xd7) > [0x7f1707726167] Try libXinerama 1.0.3. (In reply to comment #64) > Try libXinerama 1.0.3. > Same error messages. I forgot to mention xinerama is not set in my USE flags (although libXinerama was already installed as 1.0.2). The switch was made partly because of this bug. *** Bug 245129 has been marked as a duplicate of this bug. *** On sun-jdk 1.5.0.16 as virtual/{jdk,jre}, I have added :
AWT_TOOLKIT=MToolkit
with :
LIBXCB_ALLOW_SLOPPY_LOCK=1
in /etc/env.d/00local.
Else java launches but I got blank (empty) boxes instead of my java (awt) GUIs.
ref : https://answers.launchpad.net/ubuntu/+question/26562
The version that fixed the issues is not even in tree now. Closing as fixed. *** Bug 255399 has been marked as a duplicate of this bug. *** |