United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 5062728 WIN64: VM should not use Vectored Exceptions
5062728 : WIN64: VM should not use Vectored Exceptions

Details
Type:
Bug
Submit Date:
2004-06-14
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2004-12-10
Component:
hotspot
OS:
windows_2003,generic,windows_xp
Sub-Component:
runtime
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
5.0,5.0u5
Fixed Versions:
6

Related Reports
Backport:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
Our 64 bit implementations of the JVM on Windows uses Vectored Exceptions.
This causes a conflict if the Windows OS code or native libraries want to
use Structured Exceptions. 

We recently worked around a bug that was caused by the fact that Windows
uses SEH in it's implementation of malloc.  They expected to get delivered
an exception in certain rare cases but we'd instead get notified in our
VEH and terminate the program with a fatal error.
We worked around this bug 5040096 by passing control to Windows
if an access violation is generated in NTDLL but this is not a 
perfect solution.

The main reason we chose VEH was the fact that Windows could not handle
dynamically generatred code during structured exception processing.
We assumed that noone else would want to get control on access violations.

The fix to this problem is to stop using Vectored Exceptions and register
all dynamically generated code with Microsoft RtlInstallFunctionCallback
or RtlAddFunctionTable APIs.  This will allow us to register our
exception handler for our code and allow Windows to dispatch exception
to native code that used try/except blocks.
###@###.### 11/3/04 16:54 GMT

                                    

Comments
SUGGESTED FIX

Microsoft 64 bit Windows implementations no longer use frame based
exception processing for delivering it's Structured Exceptions.
C++ compilers instead must create function based data structures that
are incorporated in the .EXE and .DLL file format that Windows uses
to deliver its exceptions.  Dynamically generated code can not use
this facility since the load address and range of the generated code
is not know at compile/link time.

To work around this problem, the VM uses VectoredExceptions in
1.4.2 and 1.5 VM's on IA64 and AMD64.   VectoredExceptions are
similar to Unix signals.  This mechanism works unless native code
wishes to use structured exceptions.  In this situation, our
VectoredException handler takes control and the VM will generate
an error wince the exception was not generatred by any VM code.

A simple solution to this problem is to not allow native code to
use SEH.  This would work except for the fact that the Windows
runtime libraries, use it to implement an accelerated malloc function.
We worked around this bug in 1.5 by detecting exceptions in the
NTDLL.DLL library but this leaves us open to other libraries
in the OS doing the same thing.

The real solution is to use an API new to Win64 that allows
dynamically generated code to register it's code with the OS
so Windows can determine which exception handler to call based
on the IP address at the time of the exception.

This mechanism is not very well documented and if implemented
fully, would require us to register our prologue, frame setup,
epilog and pseudo code to unwind stack frame for each method we
compile.  One further compilcation is that the unwind data structures
are CPU dependent (IA64 and AMD64 are very different).
Rather than complicate the code in the VM and reduce and compile
time overhead, I decided to register all dynamically generated code
in the VM as a single function.  The unwind structure registered
in the VM has no unwind code definitions and contains a single
entry specifying the exception handle for this code region.

NOTE THIS FIX IS AMD64 ONLY:
The IA64 unwind information data is different from AMD64.
I could not find any Microsoft documentation describing this.
I found a reference to Intel docs but they did not match up
with the MS docs.  Since IA64 is currently not a planned release
for 1.6, I decided to make an AMD64 only fix.  Future work will have
to be done to implement this bug fix for IA64.
###@###.### 11/3/04 16:54 GMT
                                     
2004-11-03
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
dragon


                                     
2004-07-08
EVALUATION

The description says it all.

###@###.### 2004-06-14
                                     
2004-06-14



Hardware and Software, Engineered to Work Together