严重错误日志
当一个严重错误发生时候，一个附带虚拟机信息和状态的错误日志会在那个时刻点产生。
注意：这个文件的格式会随着版本的不断更新而略微有变化
这个附录包含如下内容
C.1 严重错误日志的位置
在生产环境下可以使用-XX:ErrorFile=file这个标志，用于声明文件在哪里产生，注意file代表严重错误文件的全路径，%%会被转义成%，%p会被替代成进程ID
下面例子展示了该文件会被创建在/var/log/java目录下，并且被命名为java_errorpid.log
java -XX:ErrorFile=/var/log/java/java_error%p.log
如果该标志没有被声明，虚拟机会在当前进程的工作目录下创建该文件，在该目录下无法创建文件(不能创建原因很多，例如磁盘空间不足，权限问题或者其他情况)，虚拟机会在操作系统临时目录下创建该文件，在Solaris或者linux平台下，该目录为/tmp。在windows平台下这个临时目录的值由环境变量TMP决定，当TMP的值没有定义的时候，由环境变量TEMP决定。
C.2 严重错误日志的描述
错误日志包含了在发生错误时间点上虚拟机的信息，包括下面信息：(平台不同或者版本不同有略微变化)
a、异常操作或者产生错误的信号
b、版本和配置信息
c、发生错误的线程详细信息和线程堆栈信息
d、虚拟机上的线程以及它们的状态
e、堆上的概要信息
f、加载的本地库列表
g、命令行参数
h、环境变量
i、操作系统和CPU的详细信息
注意：在某些情况下，只有这些信息的子集会被输出到错误日志中，这可能发生在如下情形：错误过于严重，以至于错误处理器无法恢复或者无法完全将信息全部获取
错误日志由一下四部分组成：
1、描述crash的头部，这是对crash的简要描述
2、线程信息
3、进程信息
4、系统信息
注意：这个格式是参照J2SE6的，因此在不同版本上会有略微不同
C.3 头部格式
头部位于每个错误日志的开始，包含了对该错误的简要描述。同时该头部信息也被打印到标准控制台上，并且如果使用Logger的话，也可能会出现在程序的日志中。
头部包含了一个HotSpot错误报告界面的URL链接，用户可以据此提请Bug报告。
下面列举一个简单示例：
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x417789d7, pid=21139, tid=1024
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b63 mixed mode, sharing)
# Problematic frame:
# C [libNativeSEGV.so+0x9d7]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
这个例子显示该虚拟机由于一个未知的信号而crash，下一行描述了信号的类型，当引起该信号时候程序计数器pc的值，进程ID，线程ID，如下所示：
# SIGSEGV (0xb) at pc=0x417789d7, pid=21139, tid=1024
| | | | +--- thread id 线程ID
| | | +------------- process id 进程ID
| | +---------------------------- program counter程序指令计数器
| | (instruction pointer)
| +----------------------------------------- signal number 信号数值
+---------------------------------------------- signal name 信号名称
下一行包含了VM的版本（Client或者Server），以及程序运行在虚拟机混合模式或者解释模式（译者注：大部分都是mix，解释模式真没见过），以及类文件共享是否被开启（译者注：类文件共享这个概念第一次听，不是很理解）
# Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b63 mixed mode, sharing)
下面的信息是描述引起crash的函数栈帧，如下所示：
# Problematic frame:
# C [libNativeSEGV.so+0x9d7]
| +-- Same as pc, but represented as library name and offset.
| For position-independent libraries (JVM and most shared
| libraries), it is possible to inspect the instructions
| that caused the crash without a debugger or core file
| by using a disassembler to dump instructions near the
| offset.
|（和程序计数器一样，但是用库名称和相应的offset来表示，对于和位置无关的库来说（一般来说JVM和大部分共享库都是位置无关的），不通过调试器或者core文件就获取到引起crash的指令是可能的，但需要使用汇编器来dump出在offset左右的指令集合（译者注：对于汇编我了解有限，仅能大概看懂，所以惭愧啊）
+----------------- Frame type （栈帧类型）
在这个例子里面，"C"栈帧类型代表本地C栈帧，下面的表格说明了可能的栈帧类型。
————————————————————————————————————————————————————————————————————————
FrameType Description
C Native C frame C栈帧
j Interpreted Java frame 解释模式Java栈帧
V VMframe VM栈帧
v VMgenerated stub frame VM生成的存根栈帧
J Other frame types, including compiled Java frames 其他栈帧（包含编译后的Java栈帧）
————————————————————————————————————————————————————————————————————————
译者注：一般估计我们看见的C或者J比较多。
虚拟机内部的错误一样会导致VM错误处理器生成一个类型的错误dump，然而头部格式是不一样，这个内部错误一般是guarantee()错误，assertion错误，ShouldNotReachHere()等等（译者注：这块我是原封不动翻译出来的，不是很明白）。下面的是一个例子展示内部错误的头部：
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# Internal Error (4F533F4C494E55583F491418160E43505000F5), pid=10226, tid=16384
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b63 mixed mode)
在上面的头部，没有信号名称或者信号数字，取而代之的是Internal Error和一个长的16进制的字符串（包含了错误发生时候的模块名称和行号），总的来说这个信息仅是供HotSpot开发者使用的。
需要注意的是，这个字符串编码可能会随着版本的不同而不同，因此很可能1.6.0的字符串不一定和1.6.1一样
总之，这里我就不翻译后面的描述了，就是一句话：
不要用这个字符串来做为关键的定位信息，如果要做的话，必须版本完全一致，完全一致请参考Oracle对于虚拟机内部版本build概念吧（注意，这段话是译者认为的）