| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2205096 | 7 | Zhengyu Gu | P3 | Closed | Fixed | b125 |
| JDK-2205963 | 6u25 | Zhengyu Gu | P3 | Closed | Fixed | b01 |
As reported in this openjdk discussion:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-June/003044.html
A C++ exception that escapes from application native code back into the VM can lead to failure modes that are unexpected, and undesirable, for the user:
Internal Error (os_windows_x86.cpp:114), pid=5024, tid=1848
guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result
from topLevelExceptionFilter
We should see if the VM can handle this condition more gracefully.
CAP member is expecting the JRE to recover from native exceptions more gracefully.
Crashing is obviously bad but so is the fact that the crash error message is very
cryptic and does not help developers track the problem down to the source.
Our own testing folk have added their voice to this bug. It seems that when we run tests on Windows via a networked drive any of the remote reads can potentially raise an exception. When that happens we get the VM crash:
guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter
http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-June/003044.html
A C++ exception that escapes from application native code back into the VM can lead to failure modes that are unexpected, and undesirable, for the user:
Internal Error (os_windows_x86.cpp:114), pid=5024, tid=1848
guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result
from topLevelExceptionFilter
We should see if the VM can handle this condition more gracefully.
CAP member is expecting the JRE to recover from native exceptions more gracefully.
Crashing is obviously bad but so is the fact that the crash error message is very
cryptic and does not help developers track the problem down to the source.
Our own testing folk have added their voice to this bug. It seems that when we run tests on Windows via a networked drive any of the remote reads can potentially raise an exception. When that happens we get the VM crash:
guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter
- backported by
-
JDK-2205096 Better VM handling of unexpected exceptions from application native code
-
- Closed
-
-
-
- Closed
-
- relates to
-
JDK-6210845 Occasional non-zero exit status errors 0xC0000005 on windows hprof/jvmti demo tests
-
- Closed
-