JDK-4898868 : JVM crash in awt!NewHandler::handler
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1_08
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-07-30
  • Updated: 2003-11-11
  • Resolved: 2003-10-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.
1.3.1_10 10Fixed
The following crash occurs in a production environment with the 1.3.1_08 Client JVM on Windows 2000.   The application uses RMI and runs within JBoss.  When the app server starts up, the object is instantiated and bound to the JNDI tree.  Other applications look up this RMI server to invoke its remote methods.  The crash only affects the JVM which is running the RMI server.  The crash occurred almost every day at one particular customer site.  

The crash dump and WinDbg output (with awt.pdb in the symbol file path) is available at /net/dtstest04.east/space/kim/822843/sakonnet_dump.dmp and windbg.txt.  With -XX:+ShowMessageBoxOnError, no dialog box appears (the debugger is lauched right away) so no Java thread dump is possible.  There is also no Hotspot error log generated.

The application had a small GUI, which has been removed, and the crash does not seem to happen as often.  Also, the crash does not occur when the RMI application is standalone, not running within JBoss.

Because the problem cannot be reproduced in a development environment, troubleshooting is limited.  For instance, -server and -Xint cannot be tested.  There is no native code in the application.  Upgrade to 1.4.x is impossible because of JBoss complications.

A quick analysis of the crash dump from CTE showed that the problem may be due to a null JNIEnv in line 77 of awt_new.cpp.

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

EVALUATION I've used windbg to inspect the following crash dump: /net/dtstest04.east/space/kim/822843/sakonnet_dump.dmp Call stack shows: awt!NewHandler::init+0x95 [../../../src/win32/native/sun/windows/awt_new.cpp @ 66] WARNING: Stack unwind information not available. Following frames may be wrong. msvcrt!callnewh+0xf jvm!JVM_FindSignal+0xf108 ----------- Based on the source code in the workspace, awt_new.cpp line 66 is the following line in NewHandler::init() _set_new_handler((_PNH)NewHandler::handler); So it likely crashed inside NewHandler::handler(). ###@###.### 2003-08-01