Java基础、中级、高级、架构面试资料

jvm crash(崩溃)文件 hs_err_pid.log 分析教程

JAVA herman 5334浏览 0评论
公告:“业余草”微信公众号提供免费CSDN下载服务(只下Java资源),关注业余草微信公众号,添加作者微信:xttblog2,发送下载链接帮助你免费下载!
本博客日IP超过2000,PV 3000 左右,急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包,请加博主新的微信号:xttblog2,之前的微信号好友位已满,备注:返现
受密码保护的文章请关注“业余草”公众号,回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽,请关注文末小程序
视频教程免费领
腾讯云】1核2G5M轻量应用服务器50元首年,高性价比,助您轻松上云

很多 java 程序员可能并没有遇到过 hs_err_pid.log 崩溃文件。并不是说他们 java 代码写的有多好,而且可能写的少。最近有网友在微信后台留言,java 程序崩溃了,生成了一个 hs_err_pid.log 文件,我该怎么办?怎么处理?于是就有了本文,带领大家一起分析 hs_err_pid.log 文件!

如果你的程序产生了  hs_err_pid.log 文件,那将是非常致命的错误。那不是你的 java 程序崩溃了,而是 JVM 虚拟机崩溃了,比你的 java 程序严重的多了,它能影响多个正在运行的 Java 进程。

当JVM发生致命错误导致崩溃时,会生成一个hs_err_pid_xxx.log这样的文件,该文件包含了导致 JVM crash 的重要信息,我们可以通过分析该文件定位到导致 JVM Crash 的原因,从而修复保证系统稳定。

默认情况下,该文件是生成在工作目录下的,当然也可以通过 JVM 参数指定生成路径:

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

这个文件主要包含如下内容:

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

分析的第一步是查看文件头:

#  SIGSEGV (0xb) at pc=0x03568cf4, pid=16819, tid=3073346448

一个非预期的错误被JRE检测到,其中:

  • SIGSEGV是信号名称
  • 0xb是信号码
  • pc=0x03568cf4指的是程序计数器的值
  • pid=16819是进程号
  • tid=3073346448是线程号

如果你对JVM有了解,应该不会对这些东西陌生。

接下来是JRE和JVM的版本信息:

# JRE version: 6.0_32-b05 
  
# Java VM: Java HotSpot(TM) Server VM (20.7-b02 mixed mode linux-x86 ) 

mixed 是一种模式,然后是问题帧的信息:

# Problematic frame: 
  
# C  [libgtk-x11-2.0.so.0+0x19fcf4]  __float128+0x19fcf4 

C:帧类型为本地帧,帧的类型包括:

  • C:本地C帧
  • j:解释的Java帧
  • V:虚拟机帧
  • v:虚拟机生成的存根栈帧
  • J:其他帧类型,包括编译后的Java帧

libgtk-x11-2.0.so.0+0x19fcf4:和程序计数器(pc)表达的含义一样,但是用的是本地so库+偏移量的方式。

再接着就是线程的信息了:

Current thread (0x09f30c00):  JavaThread "main" [_thread_in_native, id=16822, stack(0xb72a8000,0xb72f9000)] 

Current thread 是当前线程。

  • 0x09f30c00:指针
  • JavaThread:线程类型,可能的类型包括:

    • JavaThread
    • VMThread
    • CompilerThread
    • GCTaskThread
    • WatcherThread
    • ConcurrentMarkSweepThread
  • main:名字

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

再接着是信号信息:

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

这部分是导致虚拟机终止的非预期的信号信息,含义前面已经大致提到过了。其中si_errno和si_code是Linux下用来鉴别异常的,Windows下是一个ExceptionCode。

EAX=0x00000000, EBX=0x0375dd84, ECX=0x00000000, EDX=0x00000000 
ESP=0xb72f0fa0, EBP=0xb72f0fb8, ESI=0x00000000, EDI=0x0a6c1800 
EIP=0x03568cf4, EFLAGS=0x00010246, CR2=0x00000010 

接着是寄存器上下文内容:

Top of Stack: (sp=0xb72f0fa0) 
0xb72f0fa0:   00000000 00402250 0040217f 0375dd84 
0xb72f0fb0:   00000000 0a6c1800 b72f0fe8 0356c2c0 
0xb72f0fc0:   00000000 0a6c1800 b72f0fe8 003b3e77 
0xb72f0fd0:   003e6c8b 0a1a70d0 0a193358 0375dd84 
0xb72f0fe0:   0a276418 0a276418 b72f1048 03536c56 
0xb72f0ff0:   0acad000 0b3ca978 0000000c 00dd0674 
0xb72f1000:   00000003 0a2c7d50 b72f1038 0000330c 
0xb72f1010:   ffffffff ffffffff 00000001 00000001   

Instructions: (pc=0x03568cf4) 
0x03568cd4:   89 14 24 89 75 f8 89 d6 89 7d fc 89 c7 e8 7e 1b 
0x03568ce4:   ea ff 89 34 24 89 87 d4 02 00 00 e8 30 00 ea 
ff 0x03568cf4:   8b 40 10 89 3c 24 c7 44 24 08 00 00 00 00 89 87 
0x03568d04:   d0 02 00 00 8b 83 88 24 00 00 89 44 24 04 e8 dd 

栈顶程序计数器旁的操作码,它们可以被反汇编成系统崩溃前执行的指令。

Register to memory mapping:   

EAX=0x00000000 is an unknown value 
EBX=0x0375dd84: <offset 0x394d84> in /usr/lib/libgtk-x11-2.0.so.0 at 0x033c9000 
ECX=0x00000000 is an unknown value 
EDX=0x00000000 is an unknown value 
ESP=0xb72f0fa0 is pointing into the stack for thread: 0x09f30c00 
EBP=0xb72f0fb8 is pointing into the stack for thread: 0x09f30c00 
ESI=0x00000000 is an unknown value EDI=0x0a6c1800 is an unknown value 

寄存器和内存映射信息。

 JVM的hs_err_pid.log的解读

线程栈。包含了地址、栈顶、栈计数器和线程尚未使用的栈信息,由于栈可能非常长,打印的长度有限制,但是至少本地栈和Java栈都打印出来了(很多时候本地栈打印不出来,但是Java栈一般都能打印出来)。从中可以看到,Eclipse的虚拟机崩溃了。

ava Threads: ( => current thread )  
0x0b4c1000 JavaThread "Worker-247" [_thread_blocked, id=25417, stack(0x741bc000,0x7420d000)]   
0x0a300c00 JavaThread "Worker-246" [_thread_blocked, id=25235, stack(0x7d30c000,0x7d35d000)] 
... ... 

线程信息。一目了然。

VM state:not at safepoint (normal execution) 

虚拟机状态。包括:

  • not at a safepoint:正常运行状态;
  • at safepoint:所有线程都因为虚拟机等待状态而阻塞,等待一个虚拟机操作完成;
  • synchronizing:一个特殊的虚拟机操作,要求虚拟机内的其它线程保持等待状态。
VM Mutex/Monitor currently owned by a thread: None 

虚拟机的Mutex和Monitor目前没有被线程持有。Mutex是虚拟机内部的锁,而Monitor则关联到了Java对象。

堆信息。新生代、老生代、永久代。

堆信息。新生代、老生代、永久代。对JVM有了解的人应该都清楚。

Code Cache  [0xb4262000, 0xb5ac2000, 0xb7262000)  
total_blobs=5795 nmethods=5534 adapters=209 free_code_cache=25103616 largest_free_block=38336 

代码缓存(Code Cache)。这是一块用于编译和保存本地代码的内存,注意是本地代码,它和PermGen(永久代)是不一样的,永久带是用来存放Java类定义的。

Dynamic libraries: 
00101000-00122000 r-xp 00000000 08:01 3483560    /usr/lib/libjpeg.so.62.0.0 
00122000-00123000 rwxp 00020000 08:01 3483560    /usr/lib/libjpeg.so.62.0.0 
00125000-00130000 r-xp 00000000 08:01 9093202    /lib/libgcc_s-4.1.2-20080825.so.1 
00130000-00131000 rwxp 0000a000 08:01 9093202    /lib/libgcc_s-4.1.2-20080825.so.1 
... ... 

内存映射。这些信息是虚拟机崩溃时的虚拟内存列表区域。在定位崩溃原因的时候,它可以告诉你哪些类库正在被使用,位置在哪里,还有堆栈和守护页信息。就以列表中第一条为例说明:

  • 00101000-00122000:内存区域
  • r-xp:权限,r/w/x/p/s分别表示读/写/执行/私有/共享
  • 00000000:文件内的偏移量
  • 08:01:文件位置的majorID和minorID
  • 3483560:索引节点号
  • /usr/lib/libjpeg.so.62.0.0:文件位置

每一个lib都有两块虚拟内存区域——代码和数据,它们的权限不同,代码区域是r-xp;数据区域是rwxp。守护页(guard page)由权限为–xp和rwxp的一对组成。

VM Arguments: 
jvm_args: -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=256m -Xms40m -Xmx512m -Dorg.eclipse.swt.browser.XULRunnerPath=''
java_command: /.../eclipse/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -os linux -ws gtk -arch x86 -showsplash -launcher /.../eclipse/eclipse -name Eclipse ... 
Launcher Type: SUN_STANDARD

Environment Variables: 
PATH=... 
DISPLAY=:0.0 

虚拟机参数和环境变量。

Signal Handlers: 
SIGSEGV: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
... ... 

信号句柄。对于Linux下的信号机制,参阅wiki百科,链接

是不是感觉分析起来非常的麻烦,不用怕,扫描下方二维码,关注“业余草”微信公众号,我们一起学习!

后面会介绍一款工具 CrashAnalysis,它会智能的自动的给出我们分析结果,展示分析报告,而且是中文的报告哦。

业余草公众号

最后,欢迎关注我的个人微信公众号:业余草(yyucao)!可加作者微信号:xttblog2。备注:“1”,添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系!

本文原文出处:业余草: » jvm crash(崩溃)文件 hs_err_pid.log 分析教程