JDK-4963998 : VM log is not flushed when the VM aborts
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: sparc
  • Submitted: 2003-12-05
  • Updated: 2012-10-08
  • Resolved: 2004-01-21
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.

To download the current JDK release, click here.
Other
5.0 b35Fixed
Related Reports
Relates :  
JDK-4515367 - fatal error handler enhancements
Relates :  
JDK-4906990 - Infinite loop in error handler if TLS is not yet initialized.
Description
The logging functionality of 1.4.2 has regressed and is broken in 1.5 due to interactions with recent changes in the error handler.

Back-line engineers (such as myself) routinely use this feature to diagnose hard-to-reproduce crashes in the field.  It is totally unacceptable to break this functionality in 1.5.

When the VM crashes on a customer, we need as much historical information as possible about the run in order to diagnose the bug.  However, recent changes to the error handler for 4515367 have wrongly turned off log cleanup.  This means that the VM will refuse to flush its logs in exactly the cases where the logs are most critical, when the VM crashes.  This means that Sun engineers will not be able to inspect the most recent compilations.

The basic idea of 4515367 was to output crash information more robustly.  However, it is unacceptable to disable the existing information dumps, at least unconditionally (by removing the ostream_exit call).

The ostream_exit call is intended to be robust, even if the the VM is crashing.  It was designed to write diagnostic information for crashes.

If there is a strong reason not to call ostream_exit by default, then add a new flag which will allow us to get them flushed, or use LogCompilation:

   if (LogCompilation)  ostream_exit()
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b35 tiger-beta2
14-06-2004
EVALUATION From ###@###.###: ... The ostream_exit function finishes the log. It gathers side-files generated by the compiler and appends them to the main file, and then writes an epilogue onto the file. Most of this work is done in defaultStream::finish_log(). The call ostream_flush_all does not perform this final assembly. It should do it. Note that final assembly is a one-time action, and the name "flush_all" suggests that you can call it repeatedly. So I think ostream_flush_all should be renamed ostream_finish. ... In order to get called safely from abort path, some part of defaultStream::finish_log() needs to be changed to use async-safe functions, also it should avoid using large stack buffer. ###@###.### 2003-12-09 fixed in beta2 ###@###.### 2004-01-12
09-12-2003