-
Enhancement
-
Resolution: Fixed
-
P4
-
22
-
b17
-
windows
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8331767 | 21.0.4 | Goetz Lindenmaier | P4 | Resolved | Fixed | b02 |
Currently, when an exception is thrown from native code called from Java, such as:
const DWORD EX_CODE = 42;
__declspec(dllexport) void throw_C_exception() {
RaiseException(EX_CODE, EXCEPTION_NONCONTINUABLE, 0, NULL);
}
The stack is unwound until we get back to Java frames, at which point topLevelExceptionFilter in os_windows.cpp is invoked (which acts as the exception handler for the entire code cache).
Since we have no explicit handling for this exception code, we eventually end up in Handle_FLT_Exception which checks if MxCsr is modified, restores it, and then returns EXCEPTION_CONTINUE_EXECUTION. However, this is done without making sure that the exception code corresponds to an FLT* exception.
As a result, we end up entering topLevelExceptionFilter over and over, until the process finally abruptly terminates due to a stack overflow error.
We should more carefully try to filter for FLT* exception codes in Handle_FLT_Exception, so that unrecognized exceptions are handled through the default VM error reporting mechanism.
const DWORD EX_CODE = 42;
__declspec(dllexport) void throw_C_exception() {
RaiseException(EX_CODE, EXCEPTION_NONCONTINUABLE, 0, NULL);
}
The stack is unwound until we get back to Java frames, at which point topLevelExceptionFilter in os_windows.cpp is invoked (which acts as the exception handler for the entire code cache).
Since we have no explicit handling for this exception code, we eventually end up in Handle_FLT_Exception which checks if MxCsr is modified, restores it, and then returns EXCEPTION_CONTINUE_EXECUTION. However, this is done without making sure that the exception code corresponds to an FLT* exception.
As a result, we end up entering topLevelExceptionFilter over and over, until the process finally abruptly terminates due to a stack overflow error.
We should more carefully try to filter for FLT* exception codes in Handle_FLT_Exception, so that unrecognized exceptions are handled through the default VM error reporting mechanism.
- backported by
-
JDK-8331767 Improve error reporting for uncaught native exceptions on Windows
- Resolved
- relates to
-
JDK-8338353 runtime/ErrorHandling/UncaughtNativeExceptionTest.java fails on Windows aarch64
- Open
- links to
-
Commit openjdk/jdk21u-dev/ed2f5a8d
-
Commit openjdk/jdk/38bf1192
-
Review openjdk/jdk21u-dev/510
-
Review openjdk/jdk/14523
(1 links to)