Java JComboBox callback freezes Xorg

Bug #432677 reported by Aldo Nogueira on 2009-09-18
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Sun Java
New
Undecided
Unassigned
openjdk-6 (Ubuntu)
Undecided
Unassigned

Bug Description

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) wrote :
Aldo Nogueira (aldo-nogueira) wrote :

It does not matter whether Compiz is running.

Gabe Gorelick (gabegorelick) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Gabe Gorelick (gabegorelick) wrote :

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

Aldo Nogueira (aldo-nogueira) wrote :

Hum. Interesting. What is your video board?

Gabe Gorelick (gabegorelick) wrote :

Here's my whole lspci.

Aldo Nogueira (aldo-nogueira) wrote :

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) wrote :

It also happens with an ATI using the driver radeon.

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

summary: - Eclipse debugging JComboBox freezes Xorg
+ Java Thread.sleep freezes Xorg
Aldo Nogueira (aldo-nogueira) wrote :

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

Gabe Gorelick (gabegorelick) wrote :

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) wrote :

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.

Aldo Nogueira (aldo-nogueira) wrote :
summary: - Java Thread.sleep freezes Xorg
+ Java JComboBox callback freezes Xorg on Intel and ATI boards

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.

affects: ubuntu → xorg (Ubuntu)
Gabe Gorelick (gabegorelick) wrote :

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

Changed in xorg (Ubuntu):
status: New → Incomplete
Bryce Harrington (bryce) on 2009-09-25
affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Bryce Harrington (bryce) on 2009-10-09
tags: added: jaunty
Aldo Nogueira (aldo-nogueira) wrote :

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

Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed
tags: added: karmic
Dennis L. (dennis2society) wrote :

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) wrote :

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) wrote :

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.

summary: - Java JComboBox callback freezes Xorg on Intel and ATI boards
+ Java JComboBox callback freezes Xorg
Gabe Gorelick (gabegorelick) wrote :

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.

affects: xserver-xorg-video-intel (Ubuntu) → xorg (Ubuntu)
Bryce Harrington (bryce) wrote :

[xorg is not the right package for this bug]

affects: xorg (Ubuntu) → xorg-server (Ubuntu)
Dave Brosius (dbrosius) wrote :

It's not just eclipse

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

try:

-Dsun.awt.disablegrab=true

Gabe Gorelick (gabegorelick) wrote :

@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) wrote :

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?

affects: xorg-server (Ubuntu) → openjdk-6 (Ubuntu)
Gabe Gorelick (gabegorelick) wrote :

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

Matthias Klose (doko) wrote :

still seen in 6b18 and 7b89

Changed in openjdk-6 (Ubuntu):
status: Confirmed → Triaged

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.

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) wrote :

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

Harish (wherewherewhere) wrote :

Solution by @Dave Brosius works on Java 8u60

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers