JDK-6988678 : fatal error deadlock handling was unintentionally disabled
Type:Bug
Component:hotspot
Sub-Component:gc
Affected Version:hs20
Priority:P3
Status:Closed
Resolution:Fixed
OS:generic
CPU:generic
Submitted:2010-09-30
Updated:2011-04-23
Resolved:2011-04-23
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
A deadlock in the fatal error handler is normally detected by the WatcherThread, which will terminate the process after waiting for some time. This feature was unintentionally disabled.
SUGGESTED FIX
diff --git a/src/share/vm/runtime/thread.cpp b/src/share/vm/runtime/thread.cpp
--- a/src/share/vm/runtime/thread.cpp
+++ b/src/share/vm/runtime/thread.cpp
@@ -1073,7 +1073,6 @@
}
}
-#if 0
if (is_error_reported()) {
// A fatal error has happened, the error handler(VMError::report_and_die)
// should abort JVM after creating an error log file. However in some
@@ -1101,7 +1100,6 @@
os::sleep(this, 5 * 1000, false);
}
}
-#endif // #if 0
PeriodicTask::real_time_tick(time_to_wait);
30-09-2010
EVALUATION
The fix for "6423256 GC stacks should use a better data structure" included some debugging code that was not intended to be included in the product--a simple "#if 0 ... #endif" around the fatal error deadlock handling code in WatcherThread::run(). That change should be reverted.