JDK-8221743 : ErrorFile option does not handle pre-existing error files of the same name
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 13
  • Submitted: 2019-04-01
  • Updated: 2019-08-15
  • Resolved: 2019-04-08
Related Reports
CSR :  
Relates :  
Description
Summary
-------

-XX:ErrorFile="somefile" should replace "somefile" if it exists.

Problem
-------

-XX:ErrorFile="somefile" will, if "somefile" exists, silently default to "./hs_err_pid%p.log".

This is surprising behavior and can lead to errors and wasted analysis time:

- If not carefully scanning the output of the crashed processes (If that is even available!) developers may accidentally open the old error file, thinking it new, and work with them.
- Also, since we silently revert to "./hs_err_pid%p.log", we may now flood the current directory with error reports.

Note that one can use the "%p" placeholder in the name, which expands to the VM pid and bypasses this problem. But, due to PID reuse, even that may be an old file.

Solution
--------

The file should be replaced, since this is both the most expected behavior as also the behavior causing the least compatibility headaches:

Alternatives:

1) We could just fail to write a file at all, but that would deny us the hs-err file completely.

2) We could append to the file. But that is somewhat surprising and may lead to the same problem as the current solution, where one mistakes the old content at the start of the file for new output. Also, we may flood the file system.

3) We could append a suffix to the file name: May be confusing to the user since he expects the original file to find and may not check for the one with the suffix, which would be the correct one.
Again, we may flood the file system.

4) We could rename the old pre-existing file with a suffix: somewhat better than (3) but still could cause flooding the file system.

Alternative (1) is just not much help. (2)-(4) carry the risk of flooding the file system.

Specification
-------------

Patch would be very trivial. Just open the error file without O_EXCL. Currently it is opened with O_CREAT|O_EXCL.

Comments
Moving to Approved.
08-04-2019

Moving to Provisional.
06-04-2019

I'm always for improving workflow, and this is apparently something which trips over people. I fell for this multiple times and I usually know what I am doing :-) Consider this: Using ErrorFile *without* %p would be a valid way to have the jvms write to one location, always overwriting the last error report, without having to clean up old files. I think this is a valid scenario, and it would be the expected behavior. It is not strictly needed of course but it would make matters better, and that would be good.
02-04-2019

I still feel the only "problem" here is the silent change to use the default file path - but this was also discussed in JDK-8189672 and giving a warning is (or was) problematic. I won't object to this change but I don't feel it is really needed - anyone using the ErrorFile flag is likely doing their own crash file management and ensuring unique (enough) names.
02-04-2019