JDK-8189672 : -XX:ErrorFile doesn't work
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2017-10-19
  • Updated: 2019-04-02
  • Resolved: 2017-10-20
Related Reports
Relates :  
JDK-8221738 - ErrorFile option does not handle pre-existing error files of the same name
Relates :  
JDK-8221743 - ErrorFile option does not handle pre-existing error files of the same name
Relates :  
JDK-8189674 - -Djava.io.tmpdir doesn't work for generating hs_error files
Description
JVM ignores the value passed to -XX:ErrorFile
In the below crash you can see "-XX:ErrorFile=/home/fairoz/Test/hs.log" is being used but crash created in work directory /scratch/fairoz/JI/OOM/hs_err_pid39053.log

/java_re/jdk/9/all/181/binaries/linux-x64/bin/java -Djava.io.tmpdir=/home/fairoz/Test -XX:ErrorFile=/home/fairoz/Test/hs.log -XX:+CrashOnOutOfMemoryError -Xmx10m  Wrapper
Aborting due to java.lang.OutOfMemoryError: Java heap space
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (debug.cpp:340), pid=39053, tid=39054
#  fatal error: OutOfMemory encountered: Java heap space
#
# JRE version: Java(TM) SE Runtime Environment (9.0+181) (build 9+181)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" (or dumping to /scratch/fairoz/JI/OOM/core.39053)
#
# An error report file with more information is saved as:
# /scratch/fairoz/JI/OOM/hs_err_pid39053.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)
Comments
For reasons that David Holmes stated in the comments, we are closing this WNF. We agree that warning while generating error files could lead to other problems.
20-10-2017
If the path is invalid, ie we can't open the target file, or already exists, then we just fall back to the default. This seems quite reasonable as the primary goal is to produce an error file. Warnings are problematic because we can't be certain about what facility we can use to try and print the warning. Switch this to a P4 RFE if you think it worth investigating - but triage team may choose to close it out.
20-10-2017
Sorry file path was wrong "/home/fairoz/Test" instead of "/home/fmatte/Test", Interestingly it didn't complain me about that. There are 2 minor issues. 1. No complaining about invalid path 2. No warning about existance of file which gets into default error file. Can't we do anything for these above problems to consider about file creation failures?
20-10-2017
I tested this in JDK 10 on Linux and it worked for me. # An error report file with more information is saved as: # /export/users/dh198349/error.hs.log But once the file exists it won't be overwritten and you will then get the default error file. Ideally we would have some logging to show you when the file creation fails, but we can't log in this part of the error handling code.
19-10-2017