United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6918421 in-process JVM now ignores preset Windows unhandled exception filter
JDK-6918421 : in-process JVM now ignores preset Windows unhandled exception filter

Details
Type:
Bug
Submit Date:
2010-01-20
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2010-02-09
Component:
hotspot
OS:
windows
Sub-Component:
runtime
CPU:
x86
Priority:
P1
Resolution:
Fixed
Affected Versions:
6u16
Fixed Versions:
hs17 (b09)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:

Sub Tasks

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
WORK AROUND

Tell customers to use Java 1.5 with OpenOffice.org to prevent data loss.
                                     
2010-01-27
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.
                                     
2010-01-28
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.
                                     
2010-01-30
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.
                                     
2010-01-30
SUGGESTED FIX

See attached 6918421-webrev-cr0.tgz for the proposed fix.
                                     
2010-02-02
EVALUATION

ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc941df6fb7,ChangeRequest=6918421
                                     
2010-02-03
EVALUATION

ChangeSet=http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0fc941df6fb7,ChangeRequest=6918421
                                     
2010-02-26



Hardware and Software, Engineered to Work Together