Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2135479 | 5.0u8 | Steve Bohne | P4 | Closed | Fixed | b01 |
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
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
- backported by
-
JDK-2135479 WIN64: VM should not use Vectored Exceptions
- Closed
- duplicates
-
JDK-6320366 Cannot use Structured Exception Handling on Windows x64 after JVMstarted
- Closed
- relates to
-
JDK-5040096 Vtest/Vmark fail after 6 hrs run on windows2003 AMD 64bits with C2 flag
- Closed
-
JDK-6354368 Japanese IME crashes JVM on J2SE 1.5 for WindowsXP 64 bit edition
- Closed
-
JDK-8247941 Use Vectored Exception Handling on Windows
- Closed