JDK-6918421 : in-process JVM now ignores preset Windows unhandled exception filter
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u16
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2010-01-20
  • Updated: 2012-10-08
  • Resolved: 2010-02-09
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.
JDK 6 JDK 7 Other
6u19Fixed 7Fixed OpenJDK6,hs16.2Fixed
Related Reports
Relates :  
JDK-6550813 - Crash because of FPU control word being modified by native code (win32)
Description
On Windows, when a process calls SetUnhandledExceptionFilter to register its own filter F, then calls JNI_CreateJavaVM to attach a 1.6.0_16 JVM, and then (in native code, in a thread not attached to the VM) writes through a null pointer, the filter F is not called.  It used to be called, in the exact same scenario, at least with the 1.5.0_06 JVM, so this appears to be a regression.
Comments
EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0fc941df6fb7,ChangeRequest=6918421
26-02-2010
EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc941df6fb7,ChangeRequest=6918421
03-02-2010
SUGGESTED FIX See attached 6918421-webrev-cr0.tgz for the proposed fix.
02-02-2010
SUGGESTED FIX When the fix for 6550813 calls SetUnhandledExceptionFilter() it should save the previous handler value (if any). When Handle_FLT_Exception() is called, if it does not have anything to do and the previous handler value is non-NULL, then the previous handler should be called. Otherwise, returning EXCEPTION_CONTINUE_SEARCH is the right solution. I've coded up this solution and the results look very good on my Windows XP machine.
30-01-2010
EVALUATION The fix for 6550813 calls SetUnhandledExceptionFilter() and sets a new UnhandledExceptionFilter handler without saving the previous handler (if there was one). When the new handler (Handle_FLT_Exception) is called and does not have anything to do, it simply returns EXCEPTION_CONTINUE_SEARCH. According to http://msdn.microsoft.com/en-us/library/ms680634%28VS.85%29.aspx this return value does the following: Proceed with normal execution of UnhandledExceptionFilter. That means obeying the SetErrorMode flags, or invoking the Application Error pop-up message box. This isn't the right thing to do; see the suggested fix.
30-01-2010
EVALUATION This failure was introduced by the following PRT job: 20070808153955.ik199011.hs_7_6550813 Here is a pointer to the webrev for the fix: http://jruntime.east/~ik199011/my_webrevs/6550813_7.0_webrev/ The interesting part in src/os/win32/vm/os_win32.cpp is: + #ifndef _WIN64 + LONG WINAPI Handle_FLT_Exception(struct _EXCEPTION_POINTERS* exceptionInfo); + #endif void os::init_system_properties_values() { /* sysclasspath, java_home, dll_dir */ { char *home_path; char *dll_path; *** 257,266 **** --- 260,273 ---- sprintf(buf, "%s%s", Arguments::get_java_home(), ENDORSED_DIR); Arguments::set_endorsed_dirs(buf); #undef ENDORSED_DIR } + #ifndef _WIN64 + SetUnhandledExceptionFilter(Handle_FLT_Exception); + #endif + // Done return; } The fix for 6550813 was putback to: - HSX-11-B05 - JDK7-B19 (really JDK7-B20) - JDK6_10-B09 It looks like 6550813 is in state FIP for 5-pool.
28-01-2010
WORK AROUND Tell customers to use Java 1.5 with OpenOffice.org to prevent data loss.
27-01-2010