Java crash问题分析
Java的应用有时候会因为各种原因Crash,这时候会产生一个类似java_errorpid.log的错误日志。可以拿到了
这个日志,怎样分析Crash的原因呢?下面我们来详细讨论如何分析java_errorpid.log的错误日志。
一. 如何得到这个日志文件
如果有一个严重的错误引起Java进程非正常退出,我们叫Crash,这时候会产生一个日志文件。缺省情况下,这个
文件会产生在工作目录下。但是,可以在Java启动参数通过下面的设置,来改变这个文件的位置和命名规则。例如:
java -XX:ErrorFile=/var/log/java/java_error_%p.log
就将这个错误文件放在/var/log/java下,并且以java_error_pid.log的形式出现。
二.产生错误的原因
造成严重错误的原因有多种可能性。Java虚拟机自身的Bug是原因之一,但是这种可能不是很大。在绝大多数情况下,是由于系统的库文件、API或第三方的库文件造成的;系统资源的短缺也有可能造成这种严重的错误。在发生了Crash之后,如果无法定位根本原因,也应该迅速找到Work Around的方法。
三.对日志文件的分析
首先要检查日志的文件头:例如,下面是从一个客户发过来的错误日志的文件头
- -------------------------------------
- #
- # An unexpected error has been detected by HotSpot Virtual Machine:
- #
- # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0815e87e, pid=7268, tid=4360
- #
- # Java VM: Java HotSpot(TM) Server VM (1.4.2_13-b06 mixed mode)
- # Problematic frame:
- # V [jvm.dll+0x15e87e]
- #
- --------------------------------------
文件头中有很多有用的信息,“EXCEPTION_ACCESS_VIOLATION ”意味着Java应用Crash的时候,正在运行JVM自己的代码,而不是外部的Java代码或其他类库代码。这种情况很可能是JVM的Bug,但是也不一定。除了“EXCEPTION_ACCESS_VIOLATION ”,还有可能是别的信息,例如“SIGSEGV(0xb)”,意味着JVM正在执行本地或JNI的代码;“EXCEPTION_STACK_OVERFLOW”意味着这是个栈溢出的错误。(**********看到这里我们知道我报错时正在运行JVM自己的代码,而不是外部的Java代码或其他类库代码*********)
另外一个有用的JVM崩溃信息就是:
- # Problematic frame:
- # V [jvm.dll+0x15e87e]
它说明Crash的时候,JVM正在从哪个库文件执行代码。除了“V”以外,还有可能是“C”、“j”、“v”、“J”。具体的表示意思如下:
- FrameType Description:
- C: Native C frame
- j: Interpreted Java frame
- V: VMframe
- v: VMgenerated stub frame
- J: Other frame types, including compiled Java frames
- (**********看到这里我们知道我报错时是V: VMframe这种情况*********)
文件头之后,是当前线程的DUMP信息,线程之后是JVM进程的DUMP信息,包括所有线程的状态、地址和ID。最后还有JVM状态,
Heap状态,动态连接库等等的信息。这些烦乱的信息中,包含有非常有用的信息。下面我们根据几个具体的实例来分析JVM崩溃的典型例子。
四.内存回收引起的Crash
内存回收引起的Crash有以下的特点:在日志文件头一般有“ EXCEPTION_ACCESS _VIOLATION”和
“# Problematic frame: # V [jvm.dll+....”的信息,意味着这是在JVM内部处理,而且多半是JVM的Bug。
(**********看到这里我们知道我报错时意味着这是在JVM内部处理,而且多半是JVM的Bug*********)
对于这类问题,最快的方法就是绕过它。
另外,在Thread的DUMP信息最后,还能看到有关内存回收的行为例如:
- --------------- T H R E A D ---------------
- Current thread (0x00a56668): VMThread [id=4360]
- siginfo: ExceptionCode=0xc0000005, reading address 0x00000057
- Registers:
- ........
- Stack: [0x03cf0000,0x03d30000), sp=0x03d2fc18, free space=255k
- Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
- V [jvm.dll+0x15e87e]
- VM_Operation (0x063efbac): full generation collection, mode: safepoint, requested by thread 0x040f83f8
- ------------------------------------------------------------
可以清楚的看到JVM正在做 “full generation collection”。另外还有可能看到,其他的回收行为:
对于内存回收的错误,一般
- generation collection for allocation
- full generation collection
- parallel gc failed allocation
- parallel gc failed permanent allocation
- parallel gc system gc
- (***********这些错,俺都没碰到***********)
采取改变回收的算法和参数的方法来绕过去。例如,来自客户的日志除了上面的日志信息,在日志中Heap信息中还能发现一些其他信息:
- --------------------------------------------------------------
- Heap
- def new generation total 22592K, used 19530K [0x10010000, 0x11890000, 0x138f0000)
- eden space 20096K, 97% used [0x10010000, 0x11322bd8, 0x113b0000)
- from space 2496K, 0% used [0x113b0000, 0x113b0000, 0x11620000)
- to space 2496K, 0% used [0x11620000, 0x11620000, 0x11890000)
- tenured generation total 190696K, used 100019K [0x138f0000, 0x1f32a000, 0x30010000)
- the space 190696K, 52% used [0x138f0000, 0x19a9cf38, 0x19a9d000, 0x1f32a000)
- compacting perm gen total 38656K, used 38588K [0x30010000, 0x325d0000, 0x34010000)
- the space 38656K, 99% used [0x30010000, 0x325bf038, 0x325bf200, 0x325d0000)
- ----------------------------------------------------------------
上面的信息能看出在Crash的时候,JVM的PermSize空间几乎已经消耗完了,并且回收算法在压缩Perm空间的时候出了错。因此,建议改变内存回收的算法,或扩大PermSize和MaxPermSize的数值。
(*******这个倒是可以尝试*******)
五.栈溢出引起的Crash
Java代码引起的栈溢出,通常不会引起JVM的Crash,而是抛出一个Java异常:java.lang.StackOverflowError。但是在Java虚拟机中,Java的代码和本地C或C++代码公用相同的Stack。这样,在执行本地代码所造成的栈溢出,就有可能引起JVM的Crash了。栈溢出引起的Crash会在日志的文件头中看到“EXCEPTION_STACK_OVERFLOW”字样。另外,在当前线程的Stack信息中也能发现一些信息。例如下面的例子:
- -----------------------------------------------------------------------------------
- # An unexpected error has been detected by HotSpot Virtual Machine:
- #
- # EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x10001011, pid=296, tid=2940
- #
- # Java VM: Java HotSpot(TM) Client VM (1.6-internal mixed mode, sharing)
- # Problematic frame:
- # C [App.dll+0x1011]
- #
- --------------- T H R E A D ---------------
- Current thread (0x000367c0): JavaThread "main" [_thread_in_native, id=2940]
- :
- Stack: [0x00040000,0x00080000), sp=0x00041000, free space=4k
- Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
- C [App.dll+0x1011]
- C [App.dll+0x1020]
- C [App.dll+0x1020]
- :
- C [App.dll+0x1020]
- C [App.dll+0x1020]
- ......
- Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
- j Test.foo()V+0
- j Test.main([Ljava/lang/String;)V+0
- v ~StubRoutines::call_stub
- --------------------------------------------------------------------------------
在上面的信息中,可以发现这是个栈溢出的错误。并且当前栈剩余的空间已经很小了(free space =4k)。
因此建议将JVM的Stack的尺寸调大,主要设计两个参数:“-Xss” 和“-XX:StackShadowPages=n”。但是,将栈的尺寸调大,也意味着在有限的内存资源中,能打开的最大线程数会减少。
JVM致命错误日志(hs_err_pid.log)解读
致命错误出现的时候,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=, tid=
一个非预期的错误被JRE检测到,其中:
- SIGSEGV是信号名称
- 0xb是信号码
- pc=0x03568cf4指的是程序计数器的值
- pid=16819是进程号
- tid=3073346448是线程号
如果你对JVM有了解,应该不会对这些东西陌生。
接下来是JRE和JVM的版本信息:
# JRE version: .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.+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=, 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=, si_code=(SEGV_MAPERR), si_addr=×
这部分是导致虚拟机终止的非预期的信号信息,含义前面已经大致提到过了。其中si_errno和si_code是Linux下用来鉴别异常的,Windows下是一个ExceptionCode。
EAX=×,EBX=0x0375dd84,ECX=×,EDX=×
ESP=0xb72f0fa0,EBP=0xb72f0fb8,ESI=×,EDI=0x0a6c1800
EIP=0x03568cf4,EFLAGS=×,CR2=×
这是寄存器上下文。
Top of Stack: (sp=0xb72f0fa0)
0xb72f0fa0: 00000000004022500040217f 0375dd84
0xb72f0fb0: 000000000a6c1800 b72f0fe8 0356c2c0
0xb72f0fc0: 000000000a6c1800 b72f0fe8 003b3e77
0xb72f0fd0: 003e6c8b 0a1a70d0 0a193358 0375dd84
0xb72f0fe0: 0a276418 0a276418 b72f1048 03536c56
0xb72f0ff0: 0acad000 0b3ca978 0000000c 00dd0674
0xb72f1000: 000000030a2c7d50 b72f1038 0000330c
0xb72f1010: ffffffff ffffffff0000000100000001
Instructions: (pc=0x03568cf4)
0x03568cd4: 8914248975f889d6897d fc89c7 e8 7e 1b
0x03568ce4: ea ff8934248987d4020000e83000ea ff
0x03568cf4: 8b4010893c24c7442408000000008987
0x03568d04: d00200008b838824000089442404e8 dd
栈顶程序计数器旁的操作码,它们可以被反汇编成系统崩溃前执行的指令。
Register to memory mapping:
EAX=0x00000000isan unknown value
EBX=0x0375dd84: <offset 0x394d84>in/usr/lib/libgtk-x11-2.0.so. at 0x033c9000
ECX=0x00000000isan unknown value
EDX=0x00000000isan unknown value
ESP=0xb72f0fa0ispointing into the stackforthread: 0x09f30c00
EBP=0xb72f0fb8ispointing into the stackforthread: 0x09f30c00
ESI=0x00000000isan unknown value
EDI=0x0a6c1800isan unknown value
寄存器和内存映射信息。
Stack: [0xb72a8000,0xb72f9000], sp=0xb72f0fa0, free space=291k
Native frames: (J=compiled Java code, j=interpreted, Vv=VMcode,C=native code)
C [libgtk-x11-2.0.so.+0x19fcf4] __float128+0x19fcf4
C [libgtk-x11-2.0.so.+0x1a32c0] __float128+0xc0
… …
C [libswt-pi-gtk-.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=VMcode)
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+
j org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(II)I+
v ~StubRoutines::call_stub
… …
线程栈。包含了地址、栈顶、栈计数器和线程尚未使用的栈信息,由于栈可能非常长,打印的长度有限制,但是至少本地栈和Java栈都打印出来了(很多时候本地栈打印不出来,但是Java栈一般都能打印出来)。从中可以看到,Eclipse的虚拟机崩溃了。
Java Threads: ( => current thread )
0x0b4c1000 JavaThread”Worker-″[_thread_blocked, id=, stack(0x741bc000,0x7420d000)]
0x0a300c00 JavaThread”Worker-″[_thread_blocked, id=, stack(0x7d30c000,0x7d35d000)]
… …
线程信息。一目了然,不解释了。
VMstate:notat safepoint (normal execution)
虚拟机状态。包括:
- not at a safepoint:正常运行状态;
- at safepoint:所有线程都因为虚拟机等待状态而阻塞,等待一个虚拟机操作完成;
- synchronizing:一个特殊的虚拟机操作,要求虚拟机内的其它线程保持等待状态。
VMMutex/Monitor currently owned by a thread: None
虚拟机的Mutex和Monitor目前没有被线程持有。Mutex是虚拟机内部的锁,而Monitor则关联到了Java对象。
Heap
PSYoungGen total149056K, used125317K[0xa9700000, 0xb41a0000, 0xb41a0000)
eden space123520K,% used [0xa9700000,0xb0ac0de0,0xb0fa0000)
from space25536K,% used [0xb28b0000,0xb2f50748,0xb41a0000)
to space25600K,% used [0xb0fa0000,0xb0fa0000,0xb28a0000)
PSOldGen total261248K, used239964K[0x941a0000, 0xa40c0000, 0xa9700000)
object space261248K,% used [0x941a0000,0xa2bf7018,0xa40c0000)
PSPermGen total163328K, used130819K[0x841a0000, 0x8e120000, 0x941a0000)
object space163328K,% used [0x841a0000,0x8c160c40,0x8e120000)
堆信息。新生代、老生代、永久代。对JVM有了解的人应该都清楚,不解释了。
Code Cache [0xb4262000, 0xb5ac2000, 0xb7262000)
total_blobs=5795nmethods=5534adapters=209free_code_cache=25103616largest_free_block=
代码缓存(Code Cache)。这是一块用于编译和保存本地代码的内存,注意是本地代码,它和PermGen(永久代)是不一样的,永久带是用来存放Java类定义的。
Dynamic libraries:
- r-xp : /usr/lib/libjpeg.so.62.0.
- rwxp : /usr/lib/libjpeg.so.62.0.
- r-xp : /lib/libgcc_s-4.1.-.so.
- rwxp 0000a000 : /lib/libgcc_s-4.1.-.so.
... ...
内存映射。这些信息是虚拟机崩溃时的虚拟内存列表区域。在定位崩溃原因的时候,它可以告诉你哪些类库正在被使用,位置在哪里,还有堆栈和守护页信息。就以列表中第一条为例说明:
- 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的一对组成。
VMArguments:
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[]=0x7ffbfeff, sa_flags=×
SIGBUS: [libjvm.so+0x726440], sa_mask[]=0x7ffbfeff, sa_flags=×
… …
信号句柄。对于Linux下的信号机制,参阅wiki百科。
OS:Red Hat Enterprise Linux Client release 5.4 (Tikanga)
uname:Linux 2.6.-.el5 # SMP Tue Aug :: EDT i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 10240k, CORE 0k, NPROC , NOFILE , AS infinity
load average:1.78 1.58 1.54
/proc/meminfo:
…
CPU:total ( cores per cpu, threads per core) family model stepping , cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
/proc/cpuinfo:
…
Memory: 4k page, physical 3631860k(155144k free), swap 5124724k(5056452k free)
系统信息。
【转】:https://blog.csdn.net/u013339596/article/details/18562011
Java crash问题分析的更多相关文章
- 常用 Java 静态代码分析工具的分析与比较
常用 Java 静态代码分析工具的分析与比较 简介: 本文首先介绍了静态代码分析的基 本概念及主要技术,随后分别介绍了现有 4 种主流 Java 静态代码分析工具 (Checkstyle,FindBu ...
- Java线程问题分析定位
Java线程问题分析定位 分析步骤: 1.使用top命令查看系统资源占用情况,发现Java进程占用大量CPU资源,PID为11572: 2.显示进程详细列表命令:ps -mp 11572 -o THR ...
- java内存溢出分析(二)
我们继续java内存溢出分析(一)的分析,点击Details>按钮,显示如下图,我们发现有一个对象数量达到280370216个,再点击其中的List objects 点击后,显示下图 至此,我们 ...
- 性能分析之-- JAVA Thread Dump 分析综述
性能分析之-- JAVA Thread Dump 分析综述 一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工 ...
- java初学的分析
java初学的分析第一阶段:入门阶段学习目标:简单项目开发学习内容:1.Java入门书籍,Java基础知识.关于Java入门级的书,给大家推荐过<Java编程思想>.<Java核心技 ...
- Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析
文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6642463 在前面几篇文章中,我们详细介绍了A ...
- FineReport实现Java报表主题分析的效果图
Java报表-財务主题-EVA经济附加 watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmVzdF9yZXBvcnQ=/font/5a6L5L2T/font ...
- Java开源运行分析工具(转)
FProfiler FProfiler是一个非常快的Java profiler.它利用BCEL和log4j来记录每个方法从开始到结尾的日记.FProfiler可以用来在你的应用程序,Servle ...
- Java反序列化漏洞分析
相关学习资料 http://www.freebuf.com/vuls/90840.html https://security.tencent.com/index.php/blog/msg/97 htt ...
随机推荐
- c++ 读入优化、输出优化模板
0. 在有些输入数据很多的变态题中,scanf会大大拖慢程序的时间,cin就更慢了,所以就出现了读入优化.其原理就是一个一个字符的读入,输出优化同理,主要使用getchar,putchar函数. 1. ...
- MongoDB之增删改查
MongoDB的默认端口为:27017 show dbs 查看所有的数据库 MySQL和MongoDB的对应关系 MySQL MongoDB DB DB 数据库 table Collection ...
- Android 实现简单 倒计时60秒,一次1秒
倒计时功能如上图所示,其实就几行代码即可实现效果啦!!! /** 倒计时60秒,一次1秒 */ CountDownTimer timer = new CountDownTimer(60*1000, 1 ...
- LinearLayout 线性布局
android:orientation 设置布局管理器内组件的排列方式,可设置为 horizontal (水平排列).vertical (垂直排列) android:gravity 设置布局管理器内组 ...
- ionic创建工程中遇到异常、错误及解决方法
1. 创建工程——download failed ionic start myApp tabs 遇到如下错误 Downloading--Failed! Error:Timeout of 25000ms ...
- [leetcode]694. Number of Distinct Islands你究竟有几个异小岛?
Given a non-empty 2D array grid of 0's and 1's, an island is a group of 1's (representing land) conn ...
- 20165315 预备作业3 Linux安装及学习
20165315 预备作业3 Linux安装及学习 一.在自己笔记本上安装Linux操作系统 因为对操作电脑的不熟悉,我在第一项任务上就花费了一定的时间,在安装过程有如下问题: 我的电脑是苹果公司的M ...
- day 26 初识进程,验证客户端合法性
验证客户端合法性: # 1.需要认证 # 程序和用户打交道的时候才会用到用户认证 # 对所有的客户端进行统一的认证 # 我现在要做的事情 # 写一个server端 # 写一个client端 特殊的 符 ...
- Java09-java语法基础(八)java中的方法
Java09-java语法基础(八)java中的方法 一.方法(函数/过程):是一个程序块,可以完成某种功能 1.java中方法的定义格式 [访问控制修饰符] 返回值类型 方法名(参数列表){ 方 ...
- how2j网站前端项目——天猫前端(第一次)学习笔记4
开始产品页面的学习.项目里面有900多种商品,但是每种商品的布局是一致的:1.产品图片 2.基本信息 3.产品详情 4.累计评价 5.交互.从第一个产品图片开始吧! 一.产品图片 产品图片用到了分类页 ...