Where Can I Find the Java HotSpot Fatal Error Log (hs_err

Where Can I Find the Java HotSpot Fatal Error Log (hs_err_[pid] log)?

Applies To

Java SE JDK and JRE - Version 8 and later
Information in this document applies to any platform.

Introduction

This document describes where you can find the Java HotSpot Fatal Error Log and reasons the log may not be generated after a fatal error.

Depending on environment settings, the location and even the name of the Java HotSpot Fatal Error Log can vary. To learn how to easily find the log, please read the following sections.

Current Working Directory of the Process

The default location of the Java Fatal Error Log is the current working directory of the process. By default, the name of the log file is hs_err_pid.log with being the Java process ID number that encountered a fatal error.

Linux

On Linux, you can query the /proc file system, or use the lsof or jinfo commands.

ls -l /proc/<PID>/cwd

lsof -p <PID> | grep cwd

jinfo <PID> | grep user.dir

Note: On Linux, the jinfo command is available since J2SE 5.0, but depending on your kernel parameters settings, you might not be able to attach to another process. For an example, see Bug 7050524 - “SA, jinfo, jmap, jstack don’t work on Ubuntu > 10.10: DebuggerException: Can’t attach to the process”.

Windows

On Windows, download Process Explorer from Microsoft and run it. Select the process entry, and then select “Process” and “Properties…” from the menu. The value in the text field called “Current directory” is the current working directory of the process.

Note: “Depending on your kernel parameters, you might not be able to attach to another process. See JDK-7050524 SA, jinfo, jmap, jstack don’t work on Ubuntu > 10.10: DebuggerException: Can’t attach to the process.

Solaris

On Solaris 8 and later you can use the pwdx command or jinfo utility to determine the working directory of a live Java process.

/usr/bin/pwdx <PID>

jinfo <PID> | grep user.dir

Temp Directory for the Operating System

In the event that the file cannot be created in the working directory, whether due to insufficient space, permission problem, or other issue, then the file is created in the temporary directory for the operating system (OS).

Note: The environment variable TMPDIR and the Java system property called java.io.tmpdir have no effect for determining the temp directory for the Java Fatal HotSpot Error Log.

Solaris and Linux

On both Solaris and Linux, the OS temporary directory is hard coded to /tmp.

Windows

On Windows, the OS temporary directory for the Java HotSpot Fatal Error Log is determined by the Windows GetTempPath function. The GetTempPath function checks for the existence of environment variables in the following order and uses the first path found:

the path specified by the TMP environment variable
the path specified by the TEMP environment variable
the path specified by the USERPROFILE environment variable
the Windows directory

Standard Output

If the file writing to the temporary directory fails, the output goes to standard out and you will see the following message:

# Can not save log file, dump to screen..

Note: Standard output can also be redirected to a log file!

Customized Filenames and Locations

-XX:OnError=&lt;cmd&gt;

The <cmd> instruction given at -XX:OnError is executed after the JVM error handler has generated the error dump. Check the program arguments for that JVM option, because it can indicate a customized location for the Java HotSpot Fatal Error Log. Examples:

-XX:OnError="cat hs_err_pid%p.log | mail admin@foobar.com"
    -XX:OnError="mv hs_err_pid%p.log /var/cores"
    -XX:OnError="mv hs_err_pid%p.log /var/crash/java-crash-%p.log"

-XX:ErrorFile=<file>

The flag -XX:ErrorFile can be used to specify both the filename and the location where the file will be created. The substring %p is replaced by the PID. In the following example, it will result in an error log file called “/var/log/jvm-crash-<PID>.log”:

-XX:ErrorFile=/var/log/jvm_crash-%p.log

The substring %% is a special escape sequence. It is being replaced by a single %. In the following example, it will result in an error log file called “/var/crash/%p-replaced-by-<PID>”.

-XX:ErrorFile=/var/crash/%%p-replaced-by-%p

java HotSpot Fatal Error Log Suppression

Check for the following -XX options, because, if set, they can suppress the creation of the Java HotSpot Fatal Error Log. There are also some rare conditions where a Java HotSpot Fatal Error Log won’t be written.

-XX:+SuppressFatalErrorMessage

While this JVM option can be useful in rare situations when a signal handler cannot run, it simply does not dump out an hs_err_pid<pid>.log.

-XX:+ShowMessageBoxOnError

This option also suppresses the Fatal Error Log. The option is set if you need to run something (for example, attaching dbx or gdb) before generating an error dump.

-Xrs

This option reduces signal handling. This means that the JVM will not handle any internally or externally generated signals, and therefore, the JVM’s fatal signal handling code that dumps the hs_err log will not be run.

Stack Overflow

A stack overflow in Java Language code will normally result in the offending thread throwing java.lang.StackOverflowError. On the other hand, a stack overflow in native/JNI code is a fatal error which causes the process to terminate. Note that, under the hood, a pure Java API could also use native/JNI code. It may be that the process consumes all available stack space (due to a deep recursion, for example), and you may see a core file, but you may not see a Java HotSpot Fatal Error Log.

Finding the root cause of problems not your thing? It’s what we do.

JVM Performance Resources