United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4904887 : RH9:commit Japanese characters from the candidate window causes application hang

Details
Type:
Bug
Submit Date:
2003-08-12
Status:
Resolved
Updated Date:
2003-11-12
Project Name:
JDK
Resolved Date:
2003-09-30
Component:
client-libs
OS:
solaris_8,linux,linux_redhat_8.0
Sub-Component:
java.awt:i18n
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.3.1_09,1.4.1,5.0
Fixed Versions:
1.3.1_10 (10)

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Duplicate:

Sub Tasks

Description

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.


[Note]
1)I tried the test with the 2 suggested workaround for RH9.0;
 - SET LD_ASSUME_KERNEL=2.4.1
 - 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
     http://i18n-u1-26c.sfbay.sun.com:8080/jaws-i18n/test/bat/hello-i18n.html
     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.






                                    

Comments
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


                                     
2004-06-14
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
                                     
2003-09-11



Hardware and Software, Engineered to Work Together