Java JComboBox callback freezes Xorg

[Aldo Nogueira]

My machine is a desktop with an Intel Core 2 Quad, 2Gb and a video board Intel(R) 965G.
I am using Ubuntu 9.04 32 bits, Eclipse 3.5 (Galileo), Sun Java 1.6.0_16 provided by sun-java6-* packages.

Steps to reproduce (please read it until the end before trying):
 * Create a Java project in Eclipse.
 * Add the attached XLock Java class in this project
 * Put a breakpoint in the method actionPerformed()
 * Run this class (note that it has a method main()) in debug mode
 * A tiny window will appear
 * Select another animal in the combo box
 * Eclipse should stop in the breakpoint
 * All your Xorg is locked now. You can move your mouse, but nothing responds any more
 * To unlock it press CONTROL+ALT+F1, login to the terminal and kill the latest Java process
 * Everything gets back to normal

I don't know exactly where the problem is, but Xorg should never lock because of a problem in an application.

[Aldo Nogueira (aldo-nogueira)]

It does not matter whether Compiz is running.

[Gabe Gorelick (gabegorelick)]

It sounds like this may be a bug in the eclipse debugger. Eclipse 3.5 isn't supported yet in Ubuntu though. Can you confirm this in the latest Eclipse from the Ubuntu repositories? Otherwise, you may want to consider filing this bug upstream.

[Aldo Nogueira (aldo-nogueira)]

I can re-test it using Eclipse from the repository, which is incredibly old, but in my opinion, Xorg should never freeze no matter how buggy is an application.

[Gabe Gorelick (gabegorelick)]

I agree, obviously Xorg should ideally never freeze, but that isn't really possible. This is most likely a bug in how Eclipse debugger (or SWT or JFace or whatever) is interacting with X, and if I would have to guess, I'd say it is Eclipse's fault. Just my hunch though, obviously I don't have any hard evidence for believing that yet.

There is no way you can make Xorg never freeze. I'll give you a grossly oversimplified example. Let's say you ask X to draw a window for you. Now, it may be Xorg's responsibility to give you a valid, error-free window. But now let's say you ask for a million windows. It may not be in the scope of Xorg to say "No you have too many windows." Rather, that is the fault of a buggy application asking for too many windows to be drawn, thus freezing X.

[Aldo Nogueira (aldo-nogueira)]

Forget about Eclipse or SWT.
I have just executed the XLock class replacing the breakpoint with a Thread.sleep(5000). I ran it in a terminal with "$ java xlock.XLock". For five seconds, all clicks on the screen or strokes on the keyboard are ignored.

[Gabe Gorelick (gabegorelick)]

I see. And the expected behavior is that Thread.sleep shouldn't block input to Xorg entirely, rather, just input to your app, right?

[Gabe Gorelick (gabegorelick)]

I can't reproduce this with OpenJDK 6b14, which is the latest in Jaunty repos.

[Gabe Gorelick (gabegorelick)]

I also can't reproduce this with the latest Jaunty sun-java (1.6.0_16b01), X is responds normally.

[Aldo Nogueira (aldo-nogueira)]

Hum. Interesting. What is your video board?

[Gabe Gorelick (gabegorelick)]

Here's my whole lspci.

[Aldo Nogueira (aldo-nogueira)]

Your video board is a nVidia GeForce 8600M GT.
Maybe this problem occurs only with Intel drivers. A friend has just confirmed that in another machine with Intel video board, the same bug happens. For five seconds he cannot click on the Ubuntu menu or alternate to another application through ALT+TAB.

[Aldo Nogueira (aldo-nogueira)]

It also happens with an ATI using the driver radeon.

[Gabe Gorelick (gabegorelick)]

I changed the title of this bug since it doesn't have anything to do with Eclipse anymore.

[Aldo Nogueira (aldo-nogueira)]

I would rename it differently. Something like "Java JComboBox callback freezes Xorg on Intel and ATI boards"

[Gabe Gorelick (gabegorelick)]

Does this bug only occur with JComboBox? Also, doesn't it only freeze with Thread.sleep? It was probably freezing in Eclipse debugger because it is calling Thread.sleep to pause program execution.

By the way you can change the title of the bug yourself, there should be a link somewhere on the bug report to do that. Sorry I can't tell you where it is, but I'm running Launchpad Beta code, and they always change where links like that are put.

[Aldo Nogueira (aldo-nogueira)]

I could only reproduce with JComboBox. I found it because I was debugging an action in a combo box in my project.
It does not depend on Thread.sleep at all. Xorg remains frozen not matter what we put inside the action: a sleep, a long CPU intensive computation, I/O or a breakpoint. We can put Thread.sleep in other parts of the code with no effect.
This bug only occurs in Intel and ATI boards, as far as I know.
We don't need Eclipse to reproduce it.

[Gabe Gorelick (gabegorelick)]

Thanks for the clarification. So whatever action that you perform in the callback (Thread.sleep, big computation, etc.), should be run on the event-dispatching thread. This should freeze the GUI of your application, but definitely not Xorg as a whole. I'm going to mark this as a Xorg bug for now, but it may turn out this is a bug in Java, or maybe even in multiple graphics driver.

[Gabe Gorelick (gabegorelick)]

Also, can you test this on the latest Karmic release?

[Aldo Nogueira (aldo-nogueira)]

I've tested it with Karmic beta in a MacBook 4,1. Exactly the same behaviour.

[Dennis L. (dennis2society)]

I can confirm this bug on Ubuntu 9,04, 32-Bit. The desktop totally freezes when
debugging inside the Java JComboBox-callback in Eclipse. It only affects the ComboBox,
debugging a JSlider callback works fine.
This happens with Eclipse 3.5 and Eclipse 3.2 (from the Ubuntu repositories).

Most important:
This does not only happen with an ATI/AMD HD48x0 (fglrx driver, desktop effects disabled)
it also occurs with a Nvidia Geforce8400 (nvidia driver, desktop effects enabled).
So I think this bug is not restricted to ATI/AMD and Intel boards.

java version "1.6.0_16"

[Aldo Nogueira (aldo-nogueira)]

Really? Gabe reported that he could not reproduce this bug in his machine. I thought the difference was his nvidia board. Maybe we should change the title again.

[Gabe Gorelick (gabegorelick)]

Scratch that, I went back to see if I still didn't experience this, and for some reason, now I experience this bug 100% of the time. I'm not really sure why I didn't get this bug before though.

[Gabe Gorelick (gabegorelick)]

Changed the title since this bug doesn't seem to be hardware-specific. Also changed the package, since it is most definitely not intel-related.

[Bryce Harrington (bryce)]

[xorg is not the right package for this bug]

[Dave Brosius (dbrosius)]

It's not just eclipse

http://forums.netbeans.org/topic3831.html

try:

-Dsun.awt.disablegrab=true

[Gabe Gorelick (gabegorelick)]

@Dave the bug referenced in that thread is similar to this one, but that one was fixed in 6u10. It also only occurred when debugging the GUI callback, whereas comment #17 points out that this bug occurs if I/O or a CPU intensive computation occurs in the callback.

[Aldo Nogueira (aldo-nogueira)]

I've just tested the code attached here with this option Dave told us. It works. Nothing freezes but the application itself.

Thus, it's definitely not a bug in Xorg or any driver. The problem is in Java implementation for Linux.
http://bugs.sun.com/view_bug.do?bug_id=6714678

I don't agree with their solution though. It's ugly but acceptable to ask a developer to use this option when debugging an application. The problem is that when a buggy application freezes in a combobox callback, it freezes the whole system to the normal user.

What is the downside of making this option true by default?

[Gabe Gorelick (gabegorelick)]

I tried linking the upstream bug report, but Launchpad doesn't recognize Sun's bug tracker.

[Matthias Klose (doko)]

still seen in 6b18 and 7b89

[Daniel Herrmann (daniel-herrmann1)]

I know this is quite old, but I still can confirm this bug at Ubuntu 14.04 with current packets installed.

Further I can confirm it is not related to any IDE, it also happens (100% success rate) with JetBrains IntelliJ.

However it also happens in normal "running" mode, it is not dependent on whether I am debugging or not.

[Daniel Herrmann (daniel-herrmann1)]

Additional Information: Interestingly, it only happens when using System LookAndFeel. Using standard Java Look and Feel, nothing crashes, everything works as expected. Both in normal runtime mode as well as during debugging.

[Harish (wherewherewhere)]

@Daniel Herrmann, changing look and feel did not help me. The problem exists even in Mars 4.5.0, build 20150621-1200

[Harish (wherewherewhere)]

Solution by @Dave Brosius works on Java 8u60

[Karl-Philipp Richter (krichter722)]

I could reproduce the issue with

IntelliJ IDEA 2018.3.3 (Community Edition)
Build #IC-183.5153.38, built on January 9, 2019
JRE: 1.8.0_152-release-1343-b26 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.18.0-13-generic

when running a minimal Maven project around XLock.java with OpenJDK 11 on Ubuntu 18.10(!).

[Tiago Stürmer Daitx (tdaitx)]

Karl-Philipp,

Thank you for taking the time to report this bug and helping to make Ubuntu better.

However, according to this report, you do not seem to be using Ubuntu's OpenJDK and neither it is the latest version. While it was stated that OpenJDK 11 was used the actual version in the report indicates that JetBrains's VM version 1.8.0_152 was in use.

Please try to reproduce it with the most recent version in Ubuntu and let us know if you are still having this issue.

Also, please explicitly state the steps that you used to reproduce it and attach - or provide a URL link to - files required for the reproduction (as in XLock.java).

Additionally it would be nice to know if you can reproduce it as described in the original bug report in Sun (https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6714678) to be sure we are still dealing with the exact same bug.

For now I'm setting its status to Incomplete until that information is provided. You can learn more about bug statuses at http://wiki.ubuntu.com/Bugs/Status.

Thanks in advance.

[Mark Jeronimus (mark-jeronimus)]

IntelliJ IDEA *always* runs on Jetbrains JDK. It's made to run it's own bundled JDK. The JDK can be overridden but it screws with font rendering (purple edges) and possibly other things.

The application under debug, however, should *not* run on de Jetbrains JDK. While possible, the Jetbrains themselves discourages it. In project settings you look at the list of installed SDKs and see if the project uses OpenJDK or not. This is the case in my case.

It seems indeed that OpenJDK-11.0.4 which I run is affected buy this "fixed in JDK 7" bug 6714678 you linked. They talk about adding a VM argument `-Dsun.awt.disablegrab=true` and this indeeds prevents Xorg from freezing.

Simple steps to reproduce (I hope):

- sudo apt install openjdk-11-jdk
- Download IntelliJ IDEA Community edition, Extract somewhere, run
- Create new project (all settings default)
- File > Project Structure... > SDKs > Check for or add OpenJDK
- Put XLock.java in the src directory
- Remove the line `package xlock;` which is now an error
- Click next to line number 24 to toggle a breakpoint there
- Debug (green cocroach button)