JVM致命错误日志(hs_err_pid.log)分析

当jvm出现致命错误时，会生成一个错误文件 hs_err_pid<pid>.log，其中包括了导致jvm crash的重要信息，可以通过分析该文件定位到导致crash的根源，从而改善以保证系统稳定。当出现crash时，该文件默认会生成到工作目录下，然而可以通过jvm参数指定生成路径（JDK6中引入）：

-XX:ErrorFile=./hs_err_pid<pid>.log

该文件包含如下几类关键信息：

  • 日志头文件
  • 导致crash的线程信息
  • 所有线程信息
  • 安全点和锁信息
  • 堆信息
  • 本地代码缓存
  • 编译事件
  • gc相关记录
  • jvm内存映射
  • jvm启动参数
  • 服务器信息

下面用一个crash demo文件逐步解读这些信息，以便大家以后碰到crash时方便分析。

日志头文件

日志头文件包含概要信息，简述了导致crash的原因。而导致crash的原因很多，常见的原因有jvm自身的bug，应用程序错误，jvm参数配置不当，服务器资源不足，jni调用错误等。

现在参考下如下描述：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb8b18fdc6c, pid=191899, tid=140417770411776
#
# JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J  org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

这里一个重要信息是“SIGSEGV(0xb)”表示jvm crash时正在执行jni代码，而不是在执行java或者jvm的代码，如果没有在应用程序里手动调用jni代码，那么很可能是JIT动态编译时导致的该错误。其中SIGSEGV是信号名称，0xb是信号码，pc=0x00007fb8b18fdc6c指的是程序计数器的值，pid=191899是进程号，tid=140417770411776是线程号。

PS：除了“SIGSEGV(0xb)”以外，常见的描述还有“EXCEPTION_ACCESS_VIOLATION”，该描述表示jvm crash时正在执行jvm自身的代码，这往往是因为jvm的bug导致的crash；另一种常见的描述是“EXCEPTION_STACK_OVERFLOW”，该描述表示这是个栈溢出导致的错误，这往往是应用程序中存在深层递归导致的。

还有一个重要信息是：

# Problematic frame:

# J org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;

这表示出现crash时jvm正在执行的代码，这里的“J”表示正在执行java代码，后面的表示执行的方法栈。除了“J”外，还有可能是“C”、“j”、“V”、“v”，它们分别表示：

  • C: Native C frame
  • j: Interpreted Java frame
  • V: VMframe
  • v: VMgenerated stub frame
  • J: Other frame types, including compiled Java frames

加上前面对SIGSEGV(0xb)”的分析，现在可以断定是JIT动态编译导致的该错误。

查阅资料发现：

此异常是由于jdk JIT compiler optimization 导致，bug id 8021898，官网描述如下：

The JIT compiler optimization leads to a SIGSEGV or an NullPointerException at a place it must not happen.

jdk1.7.0_25到1.7.0_55这几个版本都存在此bug，1.7.0_60后修复。可通过升级jdk解决此异常，可参考 http://bugs.java.com/view_bug.do?bug_id=8021898。

到这里该问题已经分析出原因了，但是咱们可以再深入一步，分析下其它信息。

导致crash的线程信息

文件下面是导致crash的线程信息和该线程栈信息，描述信息如下：

Current thread (0x00007fb7b4014800):  JavaThread "catalina-exec-251" daemon [_thread_in_Java, id=205044, stack(0x00007fb58f435000,0x00007fb58f536000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000003f96dc9c6c

以上表示导致出错的线程是0x00007fb7b4014800（指针），线程类型是JavaThread，JavaThread表示执行的是java线程，关于该线程其它类型还可能是：

  • VMThread：jvm的内部线程
  • CompilerThread：用来调用JITing，实时编译装卸class 。 通常，jvm会启动多个线程来处理这部分工作，线程名称后面的数字也会累加，例如：CompilerThread1
  • GCTaskThread：执行gc的线程
  • WatcherThread：jvm周期性任务调度的线程，是一个单例对象。 该线程在JVM内使用得比较频繁，比如：定期的内存监控、JVM运行状况监控，还有我们经常需要去执行一些jstat 这类命令查看gc的情况
  • ConcurrentMarkSweepThread：jvm在进行CMS GC的时候，会创建一个该线程去进行GC，该线程被创建的同时会创建一个SurrogateLockerThread（简称SLT）线程并且启动它，SLT启动之后，处于等待阶段。CMST开始GC时，会发一个消息给SLT让它去获取Java层Reference对象的全局锁：Lock

后面的"catalina-exec-251"表示线程名，带有catalina前缀的线程一般是tomcat启动的线程，“daemon”表示该线程为守护线程，再后面的“[_thread_in_Java”表示线程正在执行解释或者编译后的Java代码，关于该描述其它类型还可能是：

  • _thread_in_native：线程当前状态
  • _thread_uninitialized：线程还没有创建，它只在内存原因崩溃的时候才出现
  • _thread_new：线程已经被创建，但是还没有启动
  • _thread_in_native：线程正在执行本地代码，一般这种情况很可能是本地代码有问题
  • _thread_in_vm：线程正在执行虚拟机代码
  • _thread_in_Java：线程正在执行解释或者编译后的Java代码
  • _thread_blocked：线程处于阻塞状态
  • …_trans：以_trans结尾，线程正处于要切换到其它状态的中间状态

最后的“id=205044”表示线程ID，stack(0x00007fb58f435000,0x00007fb58f536000)表示栈区间。

“siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000003f96dc9c6c”这部分是导致虚拟机终止的非预期的信号信息：其中si_errno和si_code是Linux下用来鉴别异常的，Windows下是一个ExceptionCode。

所有线程信息

再下面是线程信息：

Java Threads: ( => current thread )
  0x00007fb798015800 JavaThread "catalina-exec-280" daemon [_thread_blocked, id=206093, stack(0x00007fb58d718000,0x00007fb58d819000)]
  0x00007fb7a4016800 JavaThread "catalina-exec-279" daemon [_thread_blocked, id=206091, stack(0x00007fb58d819000,0x00007fb58d91a000)]
  ... ...(省略)
  
  Other Threads:
  0x00007fb8b4231000 VMThread [stack: 0x00007fb854eb6000,0x00007fb854fb7000] [id=192015]
  0x00007fb8b4321000 WatcherThread [stack: 0x00007fb835e6c000,0x00007fb835f6d000] [id=192414]

信息和上面介绍的类似，其中[_thread_blocked表示线程阻塞。

安全点和锁信息

再下面是安全点和锁信息：

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

安全线信息为正常运行，其它可能得描述还有：

  • not at a safepoint：正常运行状态
  • at safepoint：所有线程都因为虚拟机等待状态而阻塞，等待一个虚拟机操作完成
  • synchronizing：一个特殊的虚拟机操作，要求虚拟机内的其它线程保持等待状态

锁信息为未被线程持有，Mutex是虚拟机内部的锁，而Monitor则是synchronized锁或者其它关联到的Java对象。

堆信息

再下面是堆信息：

Heap
 par new generation   total 2293760K, used 1537284K [0x00000006f0000000, 0x0000000790000000, 0x0000000790000000)
  eden space 1966080K,  78% used [0x00000006f0000000, 0x000000074dc97aa8, 0x0000000768000000)
  from space 327680K,   0% used [0x0000000768000000, 0x00000007680a9580, 0x000000077c000000)
  to   space 327680K,   0% used [0x000000077c000000, 0x000000077c000000, 0x0000000790000000)
 concurrent mark-sweep generation total 1572864K, used 49449K [0x0000000790000000, 0x00000007f0000000, 0x00000007f0000000)
 concurrent-mark-sweep perm gen total 262144K, used 49857K [0x00000007f0000000, 0x0000000800000000, 0x0000000800000000)
 
 Card table byte_map: [0x00007fb8b8fa8000,0x00007fb8b9829000] byte_map_base: 0x00007fb8b5828000

堆信息包括：新生代、老生代、永久代信息。这里标识了使用CMS垃圾收集器。

下面的“Card table”表示一种卡表，是jvm维护的一种数据结构，用于记录更改对象时的引用，以便gc时遍历更少的table和root。

本地代码缓存

再下面是本地代码缓存信息：

Code Cache  [0x00007fb8b1000000, 0x00007fb8b1a60000, 0x00007fb8b4000000)
 total_blobs=3580 nmethods=3111 adapters=421 free_code_cache=38857Kb largest_free_block=39469312

这是一块用于编译和保存本地代码的内存；注意是本地代码，它和PermGen（永久代）是不一样的，永久代是用来存放jvm和java类的元数据的。

编译事件

再下面是本地代码编译信息：

Compilation events (10 events):
Event: 110587.798 Thread 0x00007fb8b425a800 3338             java.util.HashSet::remove (20 bytes)
Event: 110587.804 Thread 0x00007fb8b425a800 nmethod 3338 0x00007fb8b168a9d0 code [0x00007fb8b168ab60, 0x00007fb8b168afa8]
... ...（省略）
Event: 112147.387 Thread 0x00007fb8b425a800 3342             org.apache.http.impl.cookie.BestMatchSpec::formatCookies (116 bytes)
Event: 112147.465 Thread 0x00007fb8b425a800 nmethod 3342 0x00007fb8b18fcd50 code [0x00007fb8b18fd1a0, 0x00007fb8b18ff338]

可以看到，一共编译了10次；其中包含org.apache.http.impl.cookie.BestMatchSpec::formatCookies的编译；这和前面的结论相吻合。

gc相关记录

再下面是gc执行记录：

GC Heap History (10 events):
Event: 110665.975 GC heap before
{Heap before GC invocations=255 (full 31):
 par new generation   total 2293760K, used 1966777K [0x00000006f0000000, 0x0000000790000000, 0x0000000790000000)
  eden space 1966080K, 100% used [0x00000006f0000000, 0x0000000768000000, 0x0000000768000000)
  from space 327680K,   0% used [0x0000000768000000, 0x00000007680ae480, 0x000000077c000000)
  to   space 327680K,   0% used [0x000000077c000000, 0x000000077c000000, 0x0000000790000000)
 concurrent mark-sweep generation total 1572864K, used 49237K [0x0000000790000000, 0x00000007f0000000, 0x00000007f0000000)
 concurrent-mark-sweep perm gen total 262144K, used 49856K [0x00000007f0000000, 0x0000000800000000, 0x0000000800000000)
Event: 110665.981 GC heap after
Heap after GC invocations=256 (full 31):
 par new generation   total 2293760K, used 693K [0x00000006f0000000, 0x0000000790000000, 0x0000000790000000)
  eden space 1966080K,   0% used [0x00000006f0000000, 0x00000006f0000000, 0x0000000768000000)
  from space 327680K,   0% used [0x000000077c000000, 0x000000077c0ad6f8, 0x0000000790000000)
  to   space 327680K,   0% used [0x0000000768000000, 0x0000000768000000, 0x000000077c000000)
 concurrent mark-sweep generation total 1572864K, used 49237K [0x0000000790000000, 0x00000007f0000000, 0x00000007f0000000)
 concurrent-mark-sweep perm gen total 262144K, used 49856K [0x00000007f0000000, 0x0000000800000000, 0x0000000800000000)
}
... ...（省略）

可以看到gc次数为10次（full gc），然后后面描述了每次gc前后的内存信息；看一看到并没有内存不足等问题。

jvm内存映射

再下面是jvm加载的库信息：

Dynamic libraries:
00400000-00401000 r-xp 00000000 08:02 39454583                           /home/service/jdk1.7.0_55/bin/java
00600000-00601000 rw-p 00000000 08:02 39454583                           /home/service/jdk1.7.0_55/bin/java
013cd000-013ee000 rw-p 00000000 00:00 0                                  [heap]
6f0000000-800000000 rw-p 00000000 00:00 0 
3056400000-3056416000 r-xp 00000000 08:02 57409539                       /lib64/libgcc_s-4.4.7-20120601.so.1
3056416000-3056615000 ---p 00016000 08:02 57409539                       /lib64/libgcc_s-4.4.7-20120601.so.1
3056615000-3056616000 rw-p 00015000 08:02 57409539                       /lib64/libgcc_s-4.4.7-20120601.so.1
353be00000-353be20000 r-xp 00000000 08:02 57409933                       /lib64/ld-2.12.so
353c01f000-353c020000 r--p 0001f000 08:02 57409933                       /lib64/ld-2.12.so
353c020000-353c021000 rw-p 00020000 08:02 57409933                       /lib64/ld-2.12.so
... ...（省略）

这些信息是虚拟机崩溃时的虚拟内存列表区域。它可以告诉你崩溃原因时哪些类库正在被使用，位置在哪里，还有堆栈和守护页信息。以列表中第一条为例介绍下：

  • 00400000-00401000：内存区域
  • r-xp：权限，r/w/x/p/s分别表示读/写/执行/私有/共享
  • 00000000：文件内的偏移量
  • 08:02：文件位置的majorID和minorID
  • 39454583：索引节点号
  • /home/service/jdk1.7.0_55/bin/java：文件位置

jvm启动参数

再下面是jvm启动参数信息：

VM Arguments:
jvm_args: -Djava.util.logging.config.file=/home/service/tomcat7007-account-web/conf/logging.properties -Xmx4096m -Xms4096m -Xmn2560m -XX:SurvivorRatio=6 -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/home/work/webdata/logs/tomcat7007-account-web/develop/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/work/webdata/logs/tomcat7007-account-web/develop/ -Dtomcatlogdir=/home/work/webdata/logs/tomcat7007-account-web/develop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=7407 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.endorsed.dirs=/home/service/tomcat7007-account-web/endorsed -Dcatalina.base=/home/service/tomcat7007-account-web -Dcatalina.home=/home/service/tomcat7007-account-web -Djava.io.tmpdir=/home/service/tomcat7007-account-web/temp 
java_command: org.apache.catalina.startup.Bootstrap start
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=/home/service/jdk1.7.0_55
PATH=/opt/zabbix/bin:/opt/zabbix/sbin:/home/service/jdk1.7.0_55/bin:/home/work/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/work/bin
SHELL=/bin/bash

上面是jvm参数，下面是系统的环境配置。

服务器信息

再下面是服务器信息：

/proc/meminfo:
MemTotal:       65916492 kB
MemFree:        14593468 kB
Buffers:          222452 kB
Cached:         28502452 kB
SwapTotal:             0 kB
SwapFree:              0 kB
... ...（省略）
/proc/cpuinfo:
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 62
model name	: Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
stepping	: 4
... ...（省略）

上面是内存信息，主要关注下swap信息，看看有没有使用虚拟内存；下面是cpu信息。

时间： 2024-10-20 16:32:48

JVM致命错误日志(hs_err_pid.log)分析的相关文章

JVM致命错误日志（hs_err_pid.log）解读

致命错误出现的时候,JVM生成了hs_err_pid<pid>.log这样的文件,其中往往包含了虚拟机崩溃原因的重要信息.因为经常遇 到,在这篇文章里,我挑选了一个,并且逐段分析它包含的内容(文件可以在文章最后下载).默认情况下文件是创建在工作目录下的(如果没权限创建的话JVM 会尝试把文件写到/tmp这样的临时目录下面去),当然,文件格式和路径也可以通过参数指定,比如: java -XX:ErrorFile=/var/log/java/java_error%p.log 这个文件将包括: 触发

nginx web日志介绍和分析

nginx web日志介绍和分析 Nginx访问日志打印的格式可以自定义,例如Nginx日志打印格式配置如下,Log_format 用来设置日志格式,Name(模块名) Type(日志类型),可以配置多个日志模块,分别供不同的虚拟主机日志记录所调用: log_format log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '                   '$status $body_b

Log中&#39;main&#39;, &#39;system&#39;, &#39;radio&#39;, &#39;events&#39;以及android log分析

在Android中不同的log写到不同的设备中,共有/dev/log/system, /dev/log/main, /dev/log/radion, /dev/log/events四中类型.其中默认Log.v等写入/dev/log/main中.Slog写入/dev/log/system中. 我们在使用logcat 抓去日至的时候, 可以指定buffer,来请求不同的环形缓冲区 ('main', 'system', 'radio', 'events',默认为"-b main -b system&q

logstash通过rsyslog对nginx的日志收集和分析

logstash通过rsyslog对nginx的日志收集和分析 http://bbotte.blog.51cto.com/6205307/1613571 logstash&elasticsearch&kibana的安装和配置 http://bbotte.blog.51cto.com/6205307/1614453  这一篇文章里面是以nginx打补丁的方式实现rsyslog把nginx的日志同步到logstash做分析,不过线上环境种种不一样,下面是把nginx的日志直接通过rsyslog

android 常见死机问题--log分析

http://blog.csdn.net/fangchongbory/article/details/7645815 android 常见死机问题--log分析=================================================================================================== 一般在平时工作中,基本上很多代码可以在eclipse+ndk进行调试,但如果需要用到具体的硬件设备,如媒体播放设备无法模拟的情况下,只能上硬

读懂JVM垃圾收集日志

JVM垃圾收集搞懂原理很重要,但是连垃圾收集的日志都不懂,这tmd还分析个屁的问题啊,典型的空有理论知识,动手实践为零.本篇就来具体的学习一下JVM中的垃圾收集日志. 第一步,垃圾收集的选项 图1 JVM垃圾收集日志选项 图1中后面标有大拇指的是该图作者的推荐选项. -XX:+PrintGCDetails参数用于告诉虚拟机在发生垃圾收集行为时打印内存回收日志,并且在进程退出的时候输出当前内存的各区域分配情况. GC, Full GC说明了这次垃圾收集的停顿类型,而不是用来区分新生代GC还是老年代

单机部署ELK日志收集、分析系统

最近做日志分析,发现logstash较符合自己的需求, Logstash:做系统log收集,转载的工具.同时集成各类日志插件,对日志查询和分析的效率有很大的帮助.一般使用shipper作为log收集.indexer作为log转载. Logstash shipper收集log 并将log转发给redis 存储 Logstash indexer从redis中读取数据并转发给elasticsearch redis:是一个db,logstash shipper将log转发到redis数据库中存储.Log

Perl统计nginx日志信息并分析每个小时的数据

#!/usr/bin/perl # name: logcalc.pl # calc the amount of access url use strict; use warnings; use diagnostics; use File::Basename; my ($arg, $arg_only); my $FILE; my ($year, $month, $day, $mon); my ($time, $method, $url); my ($amount, $hour, $key, $va

MySQL的日志(二)：事务日志(redo log和undo log)

本文目录:1.redo log 1.1 redo log和二进制日志的区别 1.2 redo log的基本概念 1.3 日志块(log block) 1.4 log group和redo log file 1.5 redo log的格式 1.6 日志刷盘的规则 1.7 数据页刷盘的规则及checkpoint 1.8 LSN超详细分析 1.9 InnoDB的恢复行为 1.10 和redo log相关的变量2.undo log 2.1 undo log的基本概念 2.2 undo log的存储方式