JDK-4904887 : RH9:commit Japanese characters from the candidate window causes application hang
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 1.3.1_09,1.4.1,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,linux_redhat_8.0,solaris_8
  • CPU: x86,sparc
  • Submitted: 2003-08-12
  • Updated: 2003-11-12
  • Resolved: 2003-09-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
1.3.1_10 10Fixed
Related Reports
Duplicate :  
Duplicate :  

Tested OS : RedHat9.0
Tested JDK build : Tiger b14

Trying to commit Japanese characters from the candidate selection window for the conversion on the java application, the application somtimes hangs up; no response from IM.
When it works well, there is a response from IM and the application windows is activated.  When this problem occurs, the application windows isn't activated.

To reproduce,

1)Launch Notepad demo
2)Hit shift + space key and input some Japanese characters.
3)Hit space key for two times to open the candidate selection window.
4)Hit space key for some times to select the word to be converted.
5)Hit enter key to commit the selection.

Then, you can see the problem.
If you can't reproduce it with 1 trial, please try the steps for some times.
* The problem occurs intermittedly, so you may need to try the steps for some times.

1)I tried the test with the 2 suggested workaround for RH9.0;
 - rpm -i --replacefiles libc_hack.rpm

 This bug occurs also with the workarounds.
 (Withoug these two workarounds this bug occurs and VM abort also occurs)

2) This bug start to occur from b13.
   This is not reproducible with Mantis FCS, 1.4.2_01 and the Tiger builds before b12.

3) This bug is not reproducible on RH8.0

4) I saw this bug occurs on some test cases as below;

   - Demos : Notepad, Stylepad
   - Plugin application with Swing and AWT text component
     The problem is reproducible on Swing text component(no response on AWT text component and can't input any characters)
   - AWT : TextField, TextArea 

* This is the problem on RH9, but Bugtraq doesn't have RH9 for OS_Version on Customer Call inforamtion, so I put redhat8 for now.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_10 1.4.1_07 1.4.2_04 tiger FIXED IN: 1.3.1_10 1.4.1_07 1.4.2_04 tiger INTEGRATED IN: 1.3.1_10 1.4.1_07 1.4.2_04 tiger tiger-b22 VERIFIED IN: tiger

EVALUATION This problem has been reproducible since b13, in which the XAWT was integrated. That may be related to this problem. ###@###.### 2003-08-12 This problem may be revealed by the change of the XAWT, but this is essentially a dead lock problem in the X11 input method code. Here is the thread dump (snipped) of the hang. Found one Java-level deadlock: ============================= "AWT-EventQueue-0": waiting to lock monitor 0x0809dc04 (object 0x4a3671d8, a java.lang.Class) in JNI, which is held by "AWT-XAWT" "AWT-XAWT": waiting to lock monitor 0x0809dcd4 (object 0x461c0000, a sun.awt.X11.XInputMethod), which is held by "AWT-EventQueue-0" Java stack information for the threads listed above: =================================================== "AWT-EventQueue-0": at sun.awt.X11.XInputMethod.setXICFocusNative(Native Method) at sun.awt.X11.XInputMethod.setXICFocus(XInputMethod.java:58) at sun.awt.X11InputMethod.activate(X11InputMethod.java:279) - locked <0x461c0000> (a sun.awt.X11.XInputMethod) at sun.awt.im.InputContext.activateInputMethod(InputContext.java:345) at sun.awt.im.InputContext.focusGained(InputContext.java:308) - locked <0x461c6660> (a sun.awt.im.InputMethodContext) - locked <0x4662fd40> (a java.awt.Component$AWTTreeLock) at sun.awt.im.InputContext.dispatchEvent(InputContext.java:220) at sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:180) at java.awt.Component.dispatchEventImpl(Component.java:3866) at java.awt.Component.dispatchEvent(Component.java:3770) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1783) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java: 817) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:469) at java.awt.Component.dispatchEventImpl(Component.java:3805) at java.awt.Component.dispatchEvent(Component.java:3770) at sun.awt.X11.XWindow$1.run(XWindow.java:289) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:188) at java.awt.EventQueue.dispatchEvent(EventQueue.java:459) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:214) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.E ventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.ru n(EventDispatchThread.java:110) "AWT-XAWT": at sun.awt.X11InputMethod.dispatchComposedText(X11InputMethod.java:486) - waiting to lock <0x461c0000> (a sun.awt.X11.XInputMethod) at sun.awt.X11.XlibWrapper.XFilterEvent(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:473) The deadlock scenario is this: When the user selects a candidate in the lookup window, the X input method closes the lookup window. This causes a focus change, so that the X Toolkit thread posts a Java focus change event to the Java even thread. Then the X input method calls the dispatchComposedText() method, holding AWT_LOCK since it is issued inside XFilterEvent function. Meanwhile in the Java event thread, it dispatches the focus change event and try to activate the input method, since the client receives the focus from the lookup window. The activate() method is synchronized so it gets X11InputMethod object lock, then try to call setXICFocusNative method. And it tries to call some X function. At this time, the X toolkit thread is holding AWT_LOCK and try to obtain X11InputMethod object lock inside dispatchComposedText, and Java event thread is holding X11InputMethod object lock and try to obtain AWT_LOCK to call some X function. So the dead lock is expected to occur. To solve the problem, we should not try to obtain the X11InputMethod object lock on any up-call (from native to Java), such as dispatchComposedText(). Instead, ensure mutual exclusion on preedit text variables in X11InputMethod (i.e., composedText, committedText, and rawFeedback) by obtaining AWT_LOCK. ###@###.### 2003-09-11