Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

JVM 致命错误日志(hs_err_pid.log)解读

Posted on 06/27/201306/23/2019 by 四火

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

java -XX:ErrorFile=/var/log/java/java_error%p.log

这个文件将包括:

  • 触发致命错误的操作异常或者信号;
  • 版本和配置信息;
  • 触发致命异常的线程详细信息和线程栈;
  • 当前运行的线程列表和它们的状态;
  • 堆的总括信息;
  • 加载的本地库;
  • 命令行参数;
  • 环境变量;
  • 操作系统 CPU 的详细信息。

首先,看到的是对问题的概要介绍:

#  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)]

当前线程的:

  • 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

寄存器和内存映射信息。

Stack: [0xb72a8000,0xb72f9000],  sp=0xb72f0fa0,  free space=291k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libgtk-x11-2.0.so.0+0x19fcf4]  __float128+0x19fcf4
C  [libgtk-x11-2.0.so.0+0x1a32c0]  __float128+0xc0
... ...
C  [libswt-pi-gtk-3738.so+0x33f6a]  Java_org_eclipse_swt_internal_gtk_OS__1Call+0xf
J  org.eclipse.swt.internal.gtk.OS._Call(III)I
J  org.eclipse.swt.internal.gtk.OS.Call(III)I

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  org.eclipse.swt.internal.gtk.OS._Call(III)I
J  org.eclipse.swt.internal.gtk.OS.Call(III)I
j  org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(II)I+5
j  org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(II)I+17
v  ~StubRoutines::call_stub
... ...

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

Java 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 对象。

Heap
 PSYoungGen      total 149056K, used 125317K [0xa9700000, 0xb41a0000, 0xb41a0000)
  eden space 123520K, 95% used [0xa9700000,0xb0ac0de0,0xb0fa0000)
  from space 25536K, 26% used [0xb28b0000,0xb2f50748,0xb41a0000)
  to   space 25600K, 0% used [0xb0fa0000,0xb0fa0000,0xb28a0000)
 PSOldGen        total 261248K, used 239964K [0x941a0000, 0xa40c0000, 0xa9700000)
  object space 261248K, 91% used [0x941a0000,0xa2bf7018,0xa40c0000)
 PSPermGen       total 163328K, used 130819K [0x841a0000, 0x8e120000, 0x941a0000)
  object space 163328K, 80% used [0x841a0000,0x8c160c40,0x8e120000)

堆信息。新生代、老生代、永久代。对 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 百科,链接。

OS:Red Hat Enterprise Linux Client release 5.4 (Tikanga)

uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:54 EDT 2009 i686
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE 0k, NPROC 65536, NOFILE 1024, AS infinity
load average:1.78 1.58 1.54

/proc/meminfo:
...

CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

/proc/cpuinfo:
...

Memory: 4k page, physical 3631860k(155144k free), swap 5124724k(5056452k free)

系统信息。

#文中使用的 hs_err_pid 文件在此下载 #

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 常用的 JDK 自带命令行工具
  2. 过多 if-else 分支的优化
  3. 常用命令归纳:Linux/Oracle/JVM/Git
  4. LeetCode 题目解答——Easy 部分
  5. 使用堆外内存

2 thoughts on “JVM 致命错误日志(hs_err_pid.log)解读”

  1. 彭苏云 says:
    11/05/2013 at 11:56 AM

    感受到了技术的深度,谢谢分享这么好的文章。有个问题想请教下,我这边有个环境 window2003+tomcat+jna+dll,隔一段时间就会 tomcat 挂掉,产生了 hs_err_pid 文件,我找资料分析了这个文件,应该是不存在内存问题和堆栈溢出的问题,个人判断是在 java 里面利用 jna 调用 dll 时,某个地方出错了,但是进一步的排错就没思路了,希望能跟你进一步的交流,帮忙解决这个问题。

    Reply
    1. Anonymous says:
      11/08/2013 at 5:57 PM

      邮件联系,邮件地址在右上角“ 关于四火” 里面有

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme