JDK-6299259 : keyboard subsystem locks up on table editing
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: solaris_2.5.1
  • CPU: x86
  • Submitted: 2005-07-20
  • Updated: 2011-04-28
Related Reports
Relates :  
JDK-6506617 - Keyboard-lock in swing program on Linux box
Relates :  
JDK-6291992 - All editable fields get frozen.
Description
FULL PRODUCT VERSION :
All (1.4/1.5/1.6ea), previously thought only to happen on 1.5+, behaviour although less frequent also
happens on 1.4.

ADDITIONAL OS VERSION INFORMATION :
SuSE 9.3 Pro
Linux cirque-1 2.6.11.4-21.7-smp #1 SMP Thu Jun 2 14:23:14 UTC 2005 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
JTable editing can cause the entire keyboard subsystem to lock up, only
to be released upon restart of the VM. The rest of the machine keeps working
fine, the java program keeps running "fine" (mouse, focus, .. works), except
that it no longer responds to the keyboard at all.

The problems seems to be related to the SMP kernel of Linux; we haven't
been able (yet) to reproduce it on windows/osx/single kernel of Linux.

This is a duplicate of 479050, but I wanted to mention that we were able to
isolate the problem in a small program that should allow you to reproduce the
problem.

I'm attaching a zip file with a sample. We tried to strip as much from it as possible. There's a ant file that builds the example, and then you run it via a simple java -cp "./classes" com.Main

You'll see a gui pop up as in the screenshot. Click the "Toggle Edit" button to start edit mode.

The observed behaviour is: - on windows, mac, linux single processor: no problems, works as expected.
- on linux SMP: after editing for a little while, the entire keyboard locks up. Mouse stays functional, focus keeps changing as expected, application is "alive" (resize works,...), but it simply doesn't react to the keyboard anymore. All you can do is kill the app and restart it.

There's another possibility that it might be triggered via a USB keyboard -- if the linux SMP is not the problem, the USB drivers might be. I can do some more tests in case you can't reproduce it for that.

The problem is that sometimes this gets triggered after 10 seconds, sometimes after 5+ minutes; there seems to be a factor of luck involved.

It may very well be that something in my code is wrong; but in any case, the behaviour is undesirable -- the JVM should never allow to be locked up in this way.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See description.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Even if this would turn out to be a programming error; java should never lock
up the keyboard only to release it upon killing the VM.
ACTUAL -
No more keyboard.

REPRODUCIBILITY :
This bug can be reproduced always.
###@###.### 2005-07-20 11:50:26 GMT
Comments
EVALUATION After several experiments made by the customer, we've found that key events got filtered out by the IM. Here is the relevant piece of log: FINER: XKeyEvent = type = KeyPress, serial = 28516, send_event = false, display = 135199024, window = sun.awt.X11.XFocusProxyWind ow@1e4853f(3800010), root = 68, subwindow = 0, time = 3428131, x = 416, y = 110, x_root = 609, y_root = 288, state = 0, keycode = 90, same_screen = true, Sep 26, 2005 10:17:04 AM sun.awt.X11.XToolkit run FINER: KeyEvent target: sun.awt.X11.XFramePeer@13c7378(3800007), window 58,720,270 Sep 26, 2005 10:17:04 AM sun.awt.X11.XToolkit run FINE: before XFilterEvent:XKeyEvent = type = KeyPress, serial = 28516, send_event = false, display = 135199024, window = sun.awt. X11.XFocusProxyWindow@1e4853f(3800010), root = 68, subwindow = 0, time = 3428131, x = 416, y = 110, x_root = 609, y_root = 288, s tate = 0, keycode = 90, same_screen = true, Notice the last line "before XFilterEvent". During normal processing, it is followed by the "after XFilterEvent" line: FINER: XKeyEvent = type = KeyRelease, serial = 25690, send_event = false, display = 135199024, window = sun.awt.X11.XFocusProxyWi ndow@1e4853f(3800010), root = 68, subwindow = 0, time = 3418309, x = 328, y = 515, x_root = 0, y_root = 0, state = 256, keycode = 38, same_screen = false, Sep 26, 2005 10:16:54 AM sun.awt.X11.XToolkit run FINER: KeyEvent target: sun.awt.X11.XFramePeer@13c7378(3800007), window 58,720,270 Sep 26, 2005 10:16:54 AM sun.awt.X11.XToolkit run FINE: before XFilterEvent:XKeyEvent = type = KeyRelease, serial = 25690, send_event = false, display = 135199024, window = sun.aw t.X11.XFocusProxyWindow@1e4853f(3800010), root = 68, subwindow = 0, time = 3418309, x = 328, y = 515, x_root = 0, y_root = 0, sta te = 256, keycode = 38, same_screen = false, Sep 26, 2005 10:16:54 AM sun.awt.X11.XToolkit run FINE: after XFilterEvent:XKeyEvent = type = KeyRelease, serial = 25690, send_event = false, display = 135199024, window = sun.awt .X11.XFocusProxyWindow@1e4853f(3800010), root = 68, subwindow = 0, time = 3418309, x = 328, y = 515, x_root = 0, y_root = 0, stat e = 256, keycode = 38, same_screen = false, and then by the keyevent processing code which generates Java key event: Sep 26, 2005 10:16:54 AM sun.awt.X11.XBaseWindow dispatchEvent FINEST: XKeyEvent = type = KeyRelease, serial = 25690, send_event = false, display = 135199024, window = sun.awt.X11.XFocusProxyW indow@1e4853f(3800010), root = 68, subwindow = 0, time = 3418309, x = 328, y = 515, x_root = 0, y_root = 0, state = 256, keycode = 38, same_screen = false, Sep 26, 2005 10:16:54 AM sun.awt.X11.XWindow handleKeyRelease FINE: XKeyEvent = type = KeyRelease, serial = 25690, send_event = false, display = 135199024, window = sun.awt.X11.XFocusProxyWin dow@1e4853f(3800010), root = 68, subwindow = 0, time = 3418309, x = 328, y = 515, x_root = 0, y_root = 0, state = 256, keycode = 38, same_screen = false, Sep 26, 2005 10:16:54 AM sun.awt.X11.XWindow handleKeyEvent FINE: --XWindow.java:handleKeyEvent:XKeyEvent = type = KeyRelease, serial = 25690, send_event = false, display = 135199024, windo w = sun.awt.X11.XFocusProxyWindow@1e4853f(3800010), root = 68, subwindow = 0, time = 3418309, x = 328, y = 515, x_root = 0, y_roo t = 0, state = 256, keycode = 38, same_screen = false, Sep 26, 2005 10:16:54 AM sun.awt.X11.XWindow handleKeyEvent FINE: --XWindow.java:handleKeyEvent: type:3; keycode:38 Sep 26, 2005 10:16:54 AM sun.awt.X11.XWindow dumpKeysymArray FINE: 61 41 0 0 Sep 26, 2005 10:16:54 AM sun.awt.X11.XWindow handleKeyEvent FINE: XXXXXXXXXXXXXX javakeycode will be most probably:0x41 Sep 26, 2005 10:16:54 AM sun.awt.X11.XWindow handleKeyEvent FINE: >>>Fire Event:KEY_RELEASED; jkeycode:decimal=65, hex=0x41; Customer has provided the information about keyboard layout and environment settings. It appears that he has SCIM native IM installed and enabled when this happens, and en_US.UTF-8 locale. From the above information it can be noticed that the target for the key event as Java understands it is different from the target window of the X key event: Java target: XFramePeer X target: XFocusProxyWindow As of b3x, the native target for all key events in AWT/Swing is ALWAYS some XFocusProxyWindow. When we call XFilterEvent we pass Java target to input method window, and it has been suggested that this might be the cause of the problem. When we changed that target window to 0 - according to spec it means that IM will choose the target by itself based on the event, the bug disappeared. Right now customer is verifying the fix in working environment. As we couldn't reproduce the bug ourselves, we'll have to wait until the verification confirms that this fix indeed fixes the problem and doesn't cause any regressions.
06-10-2005
EVALUATION We don't have the necessary hardware to reproduce the problem so it is very hard for us to evaluate this problem. Please verify the bug again once b53 is out on the web. I checked the logs sent by submitter, but I don't see anything wrong in them. In fact, all key events are dispatched correctly - focus owner is always non-null user component, and it gets them since it changes its "toString" representation based on the text. So, if you pressed "a", toString will now return previous value + "a" - and it does so until the end of the log, in both logs. Perhaps you have the problem with painting so that you don't see the result of input?
21-09-2005
EVALUATION Might be related to 6291992. I couldn't reproduce this bug, however you can verify if it is fixed by acquiring the JRE with the fix for 6291992.
12-09-2005