`
lydawen
  • 浏览: 472111 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

jvm crash core dump分析

 
阅读更多

 

一般会有hs_err_pidxxxxx.log这么个文件,里面记录了core dump文件在哪 

在分析jvm crash 产生的core dump文件需要注意几点:

1、jdk必须使用与crash所处jdk 版本完全一致,因为不同的jdk实现有差异,将会导致gdb或jstack,jmap无法加载,或无法正确加载。至少 jstack,jmap要完全正确加载,自测是需要使用同样的jdk才可以。

2、尽可能在相同的操作系统上,这样gdb才更有可能正确加载各种动态库。

3、基于以上,在出问题的机器上进行排查是最好的。

 

===以下鸟文转自:http://www.javacodegeeks.com/2013/02/analysing-a-java-core-dump.html

但码农都清楚,技术性的文章往往都通俗易懂,没啥语法。


 

 

In this post, I will show you how you can debug a Java core file to see what caused your JVM to crash. I will be using a core file I generated in my previous post: Generating a Java Core Dump. There are different ways you can diagnose a JVM crash, listed below:

The hs_err_pid log file

When a fatal error occurs in the JVM, it produces an error log file called hs_err_pidXXXX.log, normally in the working directory of the process or in the temporary directory for the operating system. The top of this file contains the cause of the crash and the ‘problematic frame’. For example, mine shows:

$ head hs_err_pid21178.log
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000002b1d00075c, pid=21178, tid=1076017504
#
# JRE version: 6.0_21-b06
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode linux-amd64 )
# Problematic frame:
# C  [libnativelib.so+0x75c]  bar+0x10
#
 
There is also a stack trace:
Stack: [0x000000004012b000,0x000000004022c000],  sp=0x000000004022aac0,  free space=3fe0000000000000018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libnativelib.so+0x75c]  bar+0x10
C  [libnativelib.so+0x772]  foo+0xe
C  [libnativelib.so+0x78e]  Java_CoreDumper_core+0x1a
j  CoreDumper.core()V+0
j  CoreDumper.main([Ljava/lang/String;)V+7
v  ~StubRoutines::call_stub
V  [libjvm.so+0x3e756d]
 

The stack trace shows that my java method, CoreDumper.core(), called into JNI and died when the bar function was called in native code.

Debugging a Java Core Dump

In some cases, the JVM may not produce a hs_err_pid file, for example, if the native code abruptly aborts by calling the abort function. In such cases, we need to analyse the core file produced. On my machine, the operating system writes out core files to /var/tmp/cores. You can use the following command to see where your system is configured to write out core files to:

$ cat /proc/sys/kernel/core_pattern
/var/tmp/cores/%e.%p.%u.core
$ ls /var/tmp/cores
java.21178.146385.core
 

There are a few, different ways to look at core dumps:

1. Using gdb

GNU Debugger (gdb) can examine a core file and work out what the program was doing when it crashed.

$ gdb $JAVA_HOME/bin/java /var/tmp/cores/java.14015.146385.core
(gdb) where
#0  0x0000002a959bd26d in raise () from /lib64/tls/libc.so.6
#1  0x0000002a959bea6e in abort () from /lib64/tls/libc.so.6
#2  0x0000002b1cecf799 in bar () from libnativelib.so
#3  0x0000002b1cecf7a7 in foo () from libnativelib.so
#4  0x0000002b1cecf7c3 in Java_CoreDumper_core () from libnativelib.so
#5  0x0000002a971aac88 in ?? ()
#6  0x0000000040113800 in ?? ()
#7  0x0000002a9719fa42 in ?? ()
#8  0x000000004022ab10 in ?? ()
#9  0x0000002a9a4d5488 in ?? ()
#10 0x000000004022ab70 in ?? ()
#11 0x0000002a9a4d59c8 in ?? ()
#12 0x0000000000000000 in ?? ()
 

 

The where command prints the stack frames and shows that the bar function called abort() which caused the crash.

2. Using jstack

jstack prints stack traces of Java threads for a given core file.


$ jstack -J-d64 $JAVA_HOME/bin/java /var/tmp/cores/java.14015.146385.core
Debugger attached successfully.
Server compiler detected.
JVM version is 17.0-b16
Deadlock Detection:

No deadlocks found.

Thread 16788: (state = BLOCKED)

Thread 16787: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=118 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2, line=134 (Interpreted frame)
 - java.lang.ref.Finalizer$FinalizerThread.run() @bci=3, line=159 (Interpreted frame)

Thread 16786: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=485 (Interpreted frame)
 - java.lang.ref.Reference$ReferenceHandler.run() @bci=46, line=116 (Interpreted frame)

Thread 16780: (state = IN_NATIVE)
 - CoreDumper.core() @bci=0 (Interpreted frame)
 - CoreDumper.main(java.lang.String[]) @bci=7, line=12 (Interpreted frame)
 

3. Using jmap

jmap examines a core file and prints out shared object memory maps or heap memory details.

$ jmap -J-d64 $JAVA_HOME/bin/java /var/tmp/cores/java.14015.146385.core
Debugger attached successfully.
Server compiler detected.
JVM version is 17.0-b16
0x0000000040000000      49K     /usr/sunjdk/1.6.0_21/bin/java
0x0000002a9566c000      124K    /lib64/tls/libpthread.so.0
0x0000002a95782000      47K     /usr/sunjdk/1.6.0_21/jre/lib/amd64/jli/libjli.so
0x0000002a9588c000      16K     /lib64/libdl.so.2
0x0000002a9598f000      1593K   /lib64/tls/libc.so.6
0x0000002a95556000      110K    /lib64/ld-linux-x86-64.so.2
0x0000002a95bca000      11443K  /usr/sunjdk/1.6.0_21/jre/lib/amd64/server/libjvm.so
0x0000002a96699000      625K    /lib64/tls/libm.so.6
0x0000002a9681f000      56K     /lib64/tls/librt.so.1
0x0000002a96939000      65K     /usr/sunjdk/1.6.0_21/jre/lib/amd64/libverify.so
0x0000002a96a48000      228K    /usr/sunjdk/1.6.0_21/jre/lib/amd64/libjava.so
0x0000002a96b9e000      109K    /lib64/libnsl.so.1
0x0000002a96cb6000      54K     /usr/sunjdk/1.6.0_21/jre/lib/amd64/native_threads/libhpi.so
0x0000002a96de8000      57K     /lib64/libnss_files.so.2
0x0000002a96ef4000      551K    /lib64/libnss_db.so.2
0x0000002a97086000      89K     /usr/sunjdk/1.6.0_21/jre/lib/amd64/libzip.so
0x0000002b1cecf000      6K      /home/sharfah/tmp/jni/libnativelib.so

#此语句可以将heap从core dump中提取出来,成为jvm heap dump
$jmap -dump:format=b,file=dump.hprof $JAVA_HOME/bin/java java.14015.146385.core
 
 

Useful Links:

Crash course on JVM crash analysis
Generating a Java Core Dump

分享到:
评论

相关推荐

    jvm crash的崩溃日志详细分析及注意点

    分析JVM崩溃日志时,重点是定位问题所在的代码行,了解触发错误的操作,以及查看是否有内存管理问题,如堆溢出或栈溢出。同时,还要检查堆栈跟踪,确定哪些线程或方法在崩溃时刻正在执行,并结合Java堆、方法区、元...

    Jvm堆栈dump文件分析

    "Jvm堆栈dump文件分析"是指通过特定工具对这些dump文件进行解析,以便诊断和解决问题。 IBM提供了一款名为HeadAnalyzer的工具,版本4.1.4,专门用于分析Java堆栈信息,尤其适用于WebSphere应用服务器环境。...

    JVM crash 错误日志分析

    6. **核心转储(Core Dump)**:某些情况下,操作系统会生成一个核心转储文件,记录了JVM崩溃时的内存状态。结合核心转储进行分析,可以更深入地理解崩溃原因。 为了有效地分析“hs_err_pid.log”日志,我们可以...

    JAVA jvm DUMP 内存分析

    性能测试,线程的 dump 看到线程的 死锁,等待 运行状态

    好用的线程dump分析工具

    好用的线程dump分析工具

    AIX dump分析工具

    "AIX dump分析工具"是专门用于解析和理解这些dump文件的工具,帮助管理员识别并解决Java应用服务器的问题。本文将详细介绍AIX dump分析工具的工作原理、用途以及如何使用它来分析ha398.jar、ga397.zip和jca37.zip等...

    heapdump分析工具

    总的来说,heapdump分析是Java性能调优的重要手段,它可以帮助我们理解内存使用状况,找到性能瓶颈,进而优化代码和配置,提升系统的稳定性和效率。正确使用heapdump工具和相关的分析资源,是每个Java开发者必备的...

    JavaCore和HeapDump分析工具

    在分析JavaCore和HeapDump时,这些jar文件可能包含应用程序使用的类和方法,对于理解程序运行过程中的行为至关重要。例如,如果在JavaCore或HeapDump中发现特定的类或方法占用资源过多,可以追溯到这些jar文件中查找...

    mat(mac)---jvm内存分析工具

    MAT通过深入分析堆转储(heap dump)文件,提供了丰富的视图和功能,使内存管理变得更加直观和高效。 1. **内存泄漏检测**: 内存泄漏是导致Java应用性能下降和系统资源耗尽的主要原因之一。MAT通过分析堆转储文件...

    crash-dump-analysis:Java Crash Dump 分析演示的示例代码

    总结来说,"crash-dump-analysis"项目提供的示例代码是一个学习和实践Java Crash Dump分析的良好资源,它涵盖了从基础理论到实际工具使用的各个方面,对于提升Java开发者的问题诊断能力具有重要价值。通过深入研究并...

    java 内存dump分析和thread dump(java core)分析

    Java内存dump分析和Thread Dump(Java Core)是Java性能调优中的重要环节,它们能帮助开发者定位和解决系统中的各种问题,如内存泄漏、线程阻塞等。下面将详细介绍这两个概念及其分析工具。 首先,Java堆内存dump,...

    IBM分析dump文件工具

    此外,`javacore`和`heapdump`工具也是常用的WebSphere dump分析助手,它们提供了关于JVM内存和线程状态的详细信息。 对于z/OS这样的大型主机操作系统,IBM提供了Tivoli OMEGAMON工具集,其中的OMEGAMON XE for ...

    年轻代gc jvm crash

    "年轻代GC JVM crash"可能是因为在垃圾回收过程中遇到了严重问题,导致JVM崩溃。这可能是由于以下原因: 1. **内存溢出**:如果年轻代的空间不足以容纳新分配的对象,或者Survivor区无法容纳从Eden区晋升的对象,就...

    Heap Dump的IBM分析工具.zip

    理解并熟练运用heap dump分析工具是Java开发者必备的技能之一,这有助于提高应用程序的性能和稳定性。通过IBM的工具,我们可以深入理解JVM内存的工作原理,及时发现并修复内存问题,从而优化应用程序的运行效率。

    javacore\heapdump文件分析工具

    本篇文章将详细讲解如何使用`javacore`和`heapdump`分析工具,特别是针对Websphere环境的`ha`和`jca`工具,以及如何使用JDK1.6来打开和解析这些文件。 首先,`javacore`文件是Java虚拟机(JVM)在遇到特定事件(如...

    java thread dump 分析

    Java Thread Dump 分析 Java Thread Dump 分析是 Java 应用程序性能优化的重要工具之一。Thread Dump 是 JVM 的一个快照,记录了当前所有线程的状态,包括线程的 ID、名称、状态、锁信息等。通过分析 Thread Dump,...

    IBM WEBSPHERE heapdump分析工具 ha456

    ha456是一个IBM提供的轻量级heapdump分析工具,它可以帮助我们快速定位问题。 使用ha456.jar进行heapdump分析的步骤如下: 1. 将生成的heapdump.hprof文件与ha456.jar放在同一个目录下。 2. 运行heapdump.bat脚本...

    IBM thread dump文件分析工具

    在Java虚拟机(JVM)的运行过程中,有时会出现性能问题或者系统挂起的情况,这时候我们需要深入了解线程的运行状态,这就是"IBM thread dump文件分析工具"的作用所在。线程dump文件是JVM在特定时刻生成的一种快照,...

    jvm内存分析工具mat安装包

    它通过分析JVM的堆转储(Heap Dump)文件,能帮助开发者深入理解内存分配情况,找出潜在的问题。 MAT的主要功能包括: 1. **内存泄漏检测**:MAT提供了一种名为"Leak Suspects"的报告,能够快速识别可能导致内存...

    IBM heapdump分析工具

    - **IBM Memory Analyzer (MAT)**: 这是IBM提供的专业heapdump分析工具,能够帮助开发者识别内存泄漏,计算对象引用链,提供内存占用报告等。 - **JConsole**: 虽然不是IBM官方工具,但也是Java标准监控工具之一,...

Global site tag (gtag.js) - Google Analytics