JDK-4712880 : IMF Test window crashes on Win2000 Pro/zh_TW
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: generic
  • Submitted: 2002-07-10
  • Updated: 2002-11-19
  • Resolved: 2002-11-03
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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4096069 - (jni) Calling from C to Java is very slow.
Relates :  
JDK-4715177 - HotSpot does not throw a NullPointerException
Description
Test Build: j2sdk1.4.1-rc (b16)
Test Enviroment: Windows 2000 Pro/zh_TW

IMF test window crashes when clicking the "Passsive Client" area after 
having input Chinese chars in the two "Active Client" areas.

How to reproduce :

1) get the testsuite /net/sqesvr/export/i18n/i18n_merlin_ws/bundles/v1.3/b08/gs13-b08.tar.gz

2) untar the gs13-b08.tar.gz and go to GlobalSuite directory

3) run IMFTester.java file such as
%sh run_gs.sh -jdk:[PATH_JDK] test/other-functional/awt/im/spi/IMFTester.java

4) click "Start" in the "IMF Tester" window.

5) click the two "Active Client" areas of the "IMF Test Windows 0" and input
some Chinese chars.

6) then click the "Passive Client" area, test case exit, saying:
Failed: Unexpected exit from test [exit code: 1]

However, if start with the "Passive Client" areas first and then go back to
the "Active Client" areas, the problem is gone.

-----------------------------------------------------
And also it passed the merlin FCS testing under the same cofig.
This a regression bug

###@###.### 2002-07-12

The same test case hangs up on Win2000 Server/zh_TW when using jdk1.4.2 b03
with the same "active client -> passive client" running order.

###@###.### 2002-10-20
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b06 VERIFIED IN: mantis
14-06-2004
EVALUATION I would like to ask vm team's engineer to help take a look at this bug, since the crash occurs inside hotspot (jni.cpp) code so far, see the attached hs_err_pid1412.log Crash is reproducible on a English version of Windows 2000 with Simp Chinese (PRC) language package installed. If your machine does not have this language package installed, you can (1)go to ControlPandel/RegionalOptions to add it with your W2K cdrom with you (2)in "inputLocales" click "add", then select InputLocale to "Chinese(PRC)" and "keyboard Layout/IME" to "Chinese(Simplified)-MS-PintYing98" to the (3)in "general", set both "Your locale)" and "Setdefault" to "Chinese (PRC)", you will be ask to restart the machine, do it. How to reproduce (1)untar the testcase IMFTestFrame.tar attached with the bugreport (2)java IMFtestFrame (3)click into "Active Client", you should have an inputmethod status bar floating at the left-bottom of the screen, type in "zhong" then return. (you should have a Chinese character appear in the "active client" painting area. (4)then move the mouse to the "passive client" (and click into the passive client area), you will see the focus is moved to the passive client component, then the crash occurs in "jni.cpp:737 line". btw, even with "Xint", the crash still occurs. ###@###.### 2002-07-12 Can you try the flag -Xcheck:jni ? Errors in the jni calls from the source code can cause hotspot crashes, which are not actually bugs in hotspot. ###@###.### 2002-07-15 ------------------------- It was reproducible with the option -Xcheck:jni on T. Ch Windows 2000 Pro English Windows 2000 Pro with System locale S. Ch. The attached test case IMFTestFrame crashed with j2sdk1.4.1 b16. I attached the log files - one is hs_err_pid816_TW.log, which seem to be the same as Sherman's. The second one is hs_err_pid896_en_CN.log ###@###.### 2002-07-15 This is a bug in the AWT where a nonstatic method is being called through the JNI with a null receiver. However, the speedup for JNI invocations new in 1.4.1 (see 4096069) contains a code path with a crash for a null receiver. Adding a guard causes the expected NullPointerException to be thrown from within the AWT event loop. The root cause in the AWT is under investigation by ###@###.###. ###@###.### 2002-07-15 First of all, the test case throws a NullPointerException in Merlin instead of crash. This is filed as a separate bug as 4715177. Here is the root cause of this problem. When moving the mouse pointer from the active client to the passive client, the test case calls requestFocus() to the passive client, which causes InputContext.focusGained(). Within this method, it tries to commit the existing composed text (a chinese character for "zhong") in the active client. In the old implementation before the AWT new focus architecture, it just sends the InputMethodEvent to the active client, but the new AWT implementation (SendInputMethodEventToFocusOwner) sends the event to the focus component, i.e., passive client. The crash (or NullPointerException in Merlin) is caused by calling env->CallVoidMethod with m_InputMethod == NULL in SendInputMethodEvent, since m_InputMethod for the passive client is NULL at this point. ###@###.### 2002-07-16 I got some useful info from Dave Mendenhall, so I'd attach it here: --- start --- >>>Sorry for asking an old question, but I would like to know about your >>>Merlin AWT focus management implementation. In Windows environment, it >>>seems that you have changed the receiver of the InputMethodEvent from >>>the component in which the native Windows' event occurred, to the >>>current focus component, i.e., using SendInputMethodEventToFocusOwner >>>instead of SendInputMethodEvent. This seems now causing a regression. >>>So my question is that, is there any specific reason to do that change >>>for the InputMethodEvent? >>> >> > This was a long time ago, and I only faintly remember. I believe after >> reading the Input Method specification document, and looking at the >> current code, I concluded that these events were only supposed to be sent >> to the focus owner. Under the original implementation, this was always >> true. In my new implementation, there was a chance that they could be sent >> to a component other than the focus owner, and thus some additional code >> was needed to coax them into the right place. > >Actually, there is one certain case that an InputMethodEvent needs to go >to a component which does not have a focus, and this relates to the >subject bug. When the focus moves out of a component that has a >composed text, the composed text may or may not be committed depending >on the focus receiving component. If the focus receiving component >shares the same input context, the composed text should be committed in >the previously focused component, but if the focus receiving component >has its own input context, the composed text in the previously focused >component should remain intact. So whether committing or not cannot be >decided until the consecutive FOCUS_GAINED event. If we need to commit >the composed text, the InputMethodEvent should go to the previously >focused component, i.e., not focused. This has always been so before >jdk 1.4. It certainly sounds like there is a bug, then. But as I said in my last e-mail, make sure you account for the focus proxy when deterimining the previously focused component as well. No InputMethodEvent should ever go to the proxy. >> > In particular, when the Java (or 'true') focus owner is inside a >> java.awt.Window, the native focus owner is a special hidden child of the >> owning Frame or Dialog known as the 'focus proxy'. If Win32 were allowed >> to target the InputMethodEvent on its own, then the event would go to the >> 'focus proxy' rather than the true focus owner. I believe >> SendInputMethodEventToFocusOwner adjusts for this. > >Here is the code for the SendInputMethodEventToFocusOwner: Because I no longer have access to the source code, I can't trace through everything for you. And my memory is spotty on this anyway. I'm sure Denis and Oleg can help you from here. --- end --- ###@###.### 2002-07-24 Since the InputMethodEvent is not supposed to be sent to the focused component, but to the component that is associated to the current input context, there is no need to take care of FocusProxy switching. Just backing out the SendInputMethodEventToFocusOwner fixes this problem. ###@###.### 2002-10-01
01-10-2002