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的方法。

三.对日志文件的分析

首先要检查日志的文件头:例如,下面是从一个客户发过来的错误日志的文件头


  1. -------------------------------------
  2. #
  3. # An unexpected error has been detected by HotSpot Virtual Machine:
  4. #
  5. # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0815e87e, pid=7268, tid=4360
  6. #
  7. # Java VM: Java HotSpot(TM) Server VM (1.4.2_13-b06 mixed mode)
  8. # Problematic frame:
  9. # V [jvm.dll+0x15e87e]
  10. #
  11. --------------------------------------

文件头中有很多有用的信息,“EXCEPTION_ACCESS_VIOLATION ”意味着Java应用Crash的时候,正在运行JVM自己的代码,而不是外部的Java代码或其他类库代码。这种情况很可能是JVM的Bug,但是也不一定。除了“EXCEPTION_ACCESS_VIOLATION ”,还有可能是别的信息,例如“SIGSEGV(0xb)”,意味着JVM正在执行本地或JNI的代码;“EXCEPTION_STACK_OVERFLOW”意味着这是个栈溢出的错误。(**********看到这里我们知道我报错时正在运行JVM自己的代码,而不是外部的Java代码或其他类库代码*********)

另外一个有用的JVM崩溃信息就是:


  1. # Problematic frame:
  2. # V [jvm.dll+0x15e87e]

它说明Crash的时候,JVM正在从哪个库文件执行代码。除了“V”以外,还有可能是“C”、“j”、“v”、“J”。具体的表示意思如下:


  1. FrameType Description:
  2. C: Native C frame
  3. j: Interpreted Java frame
  4. V: VMframe
  5. v: VMgenerated stub frame
  6. J: Other frame types, including compiled Java frames
  7. (**********看到这里我们知道我报错时是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信息最后,还能看到有关内存回收的行为例如:


  1. --------------- T H R E A D ---------------
  2. Current thread (0x00a56668): VMThread [id=4360]
  3. siginfo: ExceptionCode=0xc0000005, reading address 0x00000057
  4. Registers:
  5. ........
  6. Stack: [0x03cf0000,0x03d30000), sp=0x03d2fc18, free space=255k
  7. Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
  8. V [jvm.dll+0x15e87e]
  9. VM_Operation (0x063efbac): full generation collection, mode: safepoint, requested by thread 0x040f83f8
  10. ------------------------------------------------------------

可以清楚的看到JVM正在做 “full generation collection”。另外还有可能看到,其他的回收行为:

对于内存回收的错误,一般


  1. generation collection for allocation
  2. full generation collection
  3. parallel gc failed allocation
  4. parallel gc failed permanent allocation
  5. parallel gc system gc
  6. (***********这些错,俺都没碰到***********)

采取改变回收的算法和参数的方法来绕过去。例如,来自客户的日志除了上面的日志信息,在日志中Heap信息中还能发现一些其他信息:


  1. --------------------------------------------------------------
  2. Heap
  3. def new generation total 22592K, used 19530K [0x10010000, 0x11890000, 0x138f0000)
  4. eden space 20096K, 97% used [0x10010000, 0x11322bd8, 0x113b0000)
  5. from space 2496K, 0% used [0x113b0000, 0x113b0000, 0x11620000)
  6. to space 2496K, 0% used [0x11620000, 0x11620000, 0x11890000)
  7. tenured generation total 190696K, used 100019K [0x138f0000, 0x1f32a000, 0x30010000)
  8. the space 190696K, 52% used [0x138f0000, 0x19a9cf38, 0x19a9d000, 0x1f32a000)
  9. compacting perm gen total 38656K, used 38588K [0x30010000, 0x325d0000, 0x34010000)
  10. the space 38656K, 99% used [0x30010000, 0x325bf038, 0x325bf200, 0x325d0000)
  11. ----------------------------------------------------------------

上面的信息能看出在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信息中也能发现一些信息。例如下面的例子:


  1. -----------------------------------------------------------------------------------
  2. # An unexpected error has been detected by HotSpot Virtual Machine:
  3. #
  4. # EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x10001011, pid=296, tid=2940
  5. #
  6. # Java VM: Java HotSpot(TM) Client VM (1.6-internal mixed mode, sharing)
  7. # Problematic frame:
  8. # C [App.dll+0x1011]
  9. #
  10. --------------- T H R E A D ---------------
  11. Current thread (0x000367c0): JavaThread "main" [_thread_in_native, id=2940]
  12. :
  13. Stack: [0x00040000,0x00080000), sp=0x00041000, free space=4k
  14. Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
  15. C [App.dll+0x1011]
  16. C [App.dll+0x1020]
  17. C [App.dll+0x1020]
  18. :
  19. C [App.dll+0x1020]
  20. C [App.dll+0x1020]
  21. ......
  22. Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
  23. j Test.foo()V+0
  24. j Test.main([Ljava/lang/String;)V+0
  25. v ~StubRoutines::call_stub
  26. --------------------------------------------------------------------------------

在上面的信息中,可以发现这是个栈溢出的错误。并且当前栈剩余的空间已经很小了(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问题分析的更多相关文章

  1. 常用 Java 静态代码分析工具的分析与比较

    常用 Java 静态代码分析工具的分析与比较 简介: 本文首先介绍了静态代码分析的基 本概念及主要技术,随后分别介绍了现有 4 种主流 Java 静态代码分析工具 (Checkstyle,FindBu ...

  2. Java线程问题分析定位

    Java线程问题分析定位 分析步骤: 1.使用top命令查看系统资源占用情况,发现Java进程占用大量CPU资源,PID为11572: 2.显示进程详细列表命令:ps -mp 11572 -o THR ...

  3. java内存溢出分析(二)

    我们继续java内存溢出分析(一)的分析,点击Details>按钮,显示如下图,我们发现有一个对象数量达到280370216个,再点击其中的List objects 点击后,显示下图 至此,我们 ...

  4. 性能分析之-- JAVA Thread Dump 分析综述

    性能分析之-- JAVA Thread Dump 分析综述       一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工 ...

  5. java初学的分析

    java初学的分析第一阶段:入门阶段学习目标:简单项目开发学习内容:1.Java入门书籍,Java基础知识.关于Java入门级的书,给大家推荐过<Java编程思想>.<Java核心技 ...

  6. Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析

    文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6642463 在前面几篇文章中,我们详细介绍了A ...

  7. FineReport实现Java报表主题分析的效果图

    Java报表-財务主题-EVA经济附加 watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmVzdF9yZXBvcnQ=/font/5a6L5L2T/font ...

  8. Java开源运行分析工具(转)

      FProfiler  FProfiler是一个非常快的Java profiler.它利用BCEL和log4j来记录每个方法从开始到结尾的日记.FProfiler可以用来在你的应用程序,Servle ...

  9. Java反序列化漏洞分析

    相关学习资料 http://www.freebuf.com/vuls/90840.html https://security.tencent.com/index.php/blog/msg/97 htt ...

随机推荐

  1. c++ 读入优化、输出优化模板

    0. 在有些输入数据很多的变态题中,scanf会大大拖慢程序的时间,cin就更慢了,所以就出现了读入优化.其原理就是一个一个字符的读入,输出优化同理,主要使用getchar,putchar函数. 1. ...

  2. MongoDB之增删改查

    MongoDB的默认端口为:27017 show  dbs   查看所有的数据库 MySQL和MongoDB的对应关系 MySQL MongoDB DB DB 数据库 table Collection ...

  3. Android 实现简单 倒计时60秒,一次1秒

    倒计时功能如上图所示,其实就几行代码即可实现效果啦!!! /** 倒计时60秒,一次1秒 */ CountDownTimer timer = new CountDownTimer(60*1000, 1 ...

  4. LinearLayout 线性布局

    android:orientation 设置布局管理器内组件的排列方式,可设置为 horizontal (水平排列).vertical (垂直排列) android:gravity 设置布局管理器内组 ...

  5. ionic创建工程中遇到异常、错误及解决方法

    1. 创建工程——download failed ionic start myApp tabs 遇到如下错误 Downloading--Failed! Error:Timeout of 25000ms ...

  6. [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 ...

  7. 20165315 预备作业3 Linux安装及学习

    20165315 预备作业3 Linux安装及学习 一.在自己笔记本上安装Linux操作系统 因为对操作电脑的不熟悉,我在第一项任务上就花费了一定的时间,在安装过程有如下问题: 我的电脑是苹果公司的M ...

  8. day 26 初识进程,验证客户端合法性

    验证客户端合法性: # 1.需要认证 # 程序和用户打交道的时候才会用到用户认证 # 对所有的客户端进行统一的认证 # 我现在要做的事情 # 写一个server端 # 写一个client端 特殊的 符 ...

  9. Java09-java语法基础(八)java中的方法

    Java09-java语法基础(八)java中的方法 一.方法(函数/过程):是一个程序块,可以完成某种功能 1.java中方法的定义格式 [访问控制修饰符]  返回值类型  方法名(参数列表){ 方 ...

  10. how2j网站前端项目——天猫前端(第一次)学习笔记4

    开始产品页面的学习.项目里面有900多种商品,但是每种商品的布局是一致的:1.产品图片 2.基本信息 3.产品详情 4.累计评价 5.交互.从第一个产品图片开始吧! 一.产品图片 产品图片用到了分类页 ...