JDK-4177508 : Japanese Win98: Running Swing demo application causes JVM crash
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 2.0,1.2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8,windows_95,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-09-30
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
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.2.0 1.2rc1Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Some Swing demo application does not run on Windows98 ja. Error dialog said stack error on KERNEL32.DLL.

FCS build "L"

Run following swing demo application,
SwingSet
Stylepad
Table/TableExample4

Application error dialog said,

JAVA �������������������� ������������������������
�������������������� : KERNEL32.DLL�������������������� : 015f:bff7431f
Registers:
EAX=8172ae70 CS=015f EIP=bff7431f EFLGS=00000283
EBX=0581ff10 SS=0167 ESP=05822044 EBP=0000803c
ECX=c155c130 DS=0167 ESI=00428b7c FS=459f
EDX=00032024 ES=0167 EDI=0000ffff GS=0000
Bytes at CS:EIP:
eb 95 8b 54 24 04 50 e8 04 00 00 00 58 c2 04 00 
Stack dump:
bff71547 00000282 72cd1511 00000000 0582207c 72cd1537 00000168 ffffffeb
00000000 00000006 00000282 72cd1511 00000000 00000000 058220a4 72cd1566

koushi.takahashi@japan 1998-09-30

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2rc1 INTEGRATED IN: 1.2rc1
14-06-2004

EVALUATION Swing is 100% java and so the probability that Swing is the culprit here is close to nil. Someone with a machine configured for Japanese and a native debugger needs to look into this. hans.muller@Eng 1998-10-01 I forgot to mention. sharman@japan might have clue. In his workspace, there are no crash, swing works. He's working on 2D stuffs. Could be something related to that. koushi.takahashi@japan 1998-10-02 The crash does happen on my machine with jdk release image. The actually crash happens in win98 kernel32 dll with stack overflow. At that moment, the stack of full of a special data structure allocated by kernel32. NOTE: the data structure is not call frame. The thread causes the problem is the awt main thread. ###@###.### 1998-10-08 After digging into the problem, I found the actual crash happens in PeekMessage system call inside AwtToolkit::PumpWaitingMessage(), there is some race condition inside the system. The call is very likely crash at the third time it is called. By that time, there is no message in the queue, since the hook function is nevery called. When the crash happens, the return address of this call site is destroyed. There must be something very wrong inside system call. I don't see any reason this call would fail. ###@###.### 1998-10-20 After intensive debugging, I find the code crash inside win32 DefWindowProc(), and it turns out that there is a bug in win98 JP IME (input method engine). The win98 JP user need to install the IME-SR1 to fix this problem. In the following section, I would provide more detail information for people who is insterested in. //////////////////////////////////////////////////////////////////////// The problem is close related to input method plus race condition. After extensive searching, I have narrow down the problem to WM_IME_NOTIFY. In normal case, the SwingSet demo will receive only one WM_IME_NOTIFY, IMN_OPENSTATUSWINDOW (that is the case when I use with my "all" target"). The code is at line 800 of awt_Component.cpp, win32/native/sun/windows. It will call WmImeNotify(), which normally do nothing, and it will further pass the message back to DefWindowProc(...). When I use the release target, the message loop will receive *3* WM_IME_NOTIFY message during the startup. For the third event, the code will call WmImeNotify() (which does nothing) and call the DefWindowProc(...), which in turn call the ::CallWindowProc((FARPROC)m_DefWindowProc, GetHWnd(), msg, wParam, lParam), and it crashed inside the call. All the arguments are correct. So the only possible reason is there is bug in win98. By the way, the 3 event are: WM_IME_NOTIFY, IMN_SETCOMPOSITIONWINDOW, WM_IME_NOTIFY, IMN_OPENSTATUSWINDOW WM_IME_NOTIFY, IMN_OPENSTATUSWINDOW ###@###.### 1998-10-26 Hi, Seems like I got the win98 problme, I believe it's the MS-IME98 bug and should be solved by the newest <MSIME98-SR1>. In MS's web bug datebase, I found a similar bug which says that the "old" ms-ims98 may cause some normal application crashed in some situations, just like we are facing in jdk1.2fcs, the bug report also metions that "this bug is a little difficult to reproduce/track, so there is no "patch" yet, but after I installed the MSIME98-SR1 (the Service Release 1 update version of ime98), there is no crash occured by using the same sample and the same image including the fcs-O jre binary, looks like the ime98-sr1 has fixed this problem even it does not mention it in it's readme file. FYI: (1)This bug could also be workarounded by setting the default language to US (set the language and keyboard layout to US instead of the current Japanese MSIME98 as the default in the ControlPanel/keyboard), then the user could switch back to the Japanese keyboard layout by "Left Alf+Shift". (2)The URL of the bug report at MS's web side (in Japanese): http://www.microsoft.com/mscorp/worldwide/japan/support/kb/articles/J042/9/56.htm (3)The URL of IME98-SR1 (in Japanese) http://www.micorsoft.com/japan/office/officefreestuff/ime/ime98sr1/ Hong, could you check your current 98-ja to find what's the version of the ime98? and install the ime98-SR1 to verify if the crash still occurs or not? If you could not read Japanese, you may ask the IBM engineer Sato-san to help you install the "patch" (Ask norbert if you have not met Sato-san yet). Roger, I suggest we should put some documents in the README file to metion this bug. And, I will begin to look at the Chinese bugs you mentioned. Thanx, xueming
11-06-2004