一般会有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崩溃日志时,重点是定位问题所在的代码行,了解触发错误的操作,以及查看是否有内存管理问题,如堆溢出或栈溢出。同时,还要检查堆栈跟踪,确定哪些线程或方法在崩溃时刻正在执行,并结合Java堆、方法区、元...
"Jvm堆栈dump文件分析"是指通过特定工具对这些dump文件进行解析,以便诊断和解决问题。 IBM提供了一款名为HeadAnalyzer的工具,版本4.1.4,专门用于分析Java堆栈信息,尤其适用于WebSphere应用服务器环境。...
6. **核心转储(Core Dump)**:某些情况下,操作系统会生成一个核心转储文件,记录了JVM崩溃时的内存状态。结合核心转储进行分析,可以更深入地理解崩溃原因。 为了有效地分析“hs_err_pid.log”日志,我们可以...
性能测试,线程的 dump 看到线程的 死锁,等待 运行状态
好用的线程dump分析工具
"AIX dump分析工具"是专门用于解析和理解这些dump文件的工具,帮助管理员识别并解决Java应用服务器的问题。本文将详细介绍AIX dump分析工具的工作原理、用途以及如何使用它来分析ha398.jar、ga397.zip和jca37.zip等...
总的来说,heapdump分析是Java性能调优的重要手段,它可以帮助我们理解内存使用状况,找到性能瓶颈,进而优化代码和配置,提升系统的稳定性和效率。正确使用heapdump工具和相关的分析资源,是每个Java开发者必备的...
在分析JavaCore和HeapDump时,这些jar文件可能包含应用程序使用的类和方法,对于理解程序运行过程中的行为至关重要。例如,如果在JavaCore或HeapDump中发现特定的类或方法占用资源过多,可以追溯到这些jar文件中查找...
MAT通过深入分析堆转储(heap dump)文件,提供了丰富的视图和功能,使内存管理变得更加直观和高效。 1. **内存泄漏检测**: 内存泄漏是导致Java应用性能下降和系统资源耗尽的主要原因之一。MAT通过分析堆转储文件...
总结来说,"crash-dump-analysis"项目提供的示例代码是一个学习和实践Java Crash Dump分析的良好资源,它涵盖了从基础理论到实际工具使用的各个方面,对于提升Java开发者的问题诊断能力具有重要价值。通过深入研究并...
Java内存dump分析和Thread Dump(Java Core)是Java性能调优中的重要环节,它们能帮助开发者定位和解决系统中的各种问题,如内存泄漏、线程阻塞等。下面将详细介绍这两个概念及其分析工具。 首先,Java堆内存dump,...
此外,`javacore`和`heapdump`工具也是常用的WebSphere dump分析助手,它们提供了关于JVM内存和线程状态的详细信息。 对于z/OS这样的大型主机操作系统,IBM提供了Tivoli OMEGAMON工具集,其中的OMEGAMON XE for ...
"年轻代GC JVM crash"可能是因为在垃圾回收过程中遇到了严重问题,导致JVM崩溃。这可能是由于以下原因: 1. **内存溢出**:如果年轻代的空间不足以容纳新分配的对象,或者Survivor区无法容纳从Eden区晋升的对象,就...
理解并熟练运用heap dump分析工具是Java开发者必备的技能之一,这有助于提高应用程序的性能和稳定性。通过IBM的工具,我们可以深入理解JVM内存的工作原理,及时发现并修复内存问题,从而优化应用程序的运行效率。
本篇文章将详细讲解如何使用`javacore`和`heapdump`分析工具,特别是针对Websphere环境的`ha`和`jca`工具,以及如何使用JDK1.6来打开和解析这些文件。 首先,`javacore`文件是Java虚拟机(JVM)在遇到特定事件(如...
Java Thread Dump 分析 Java Thread Dump 分析是 Java 应用程序性能优化的重要工具之一。Thread Dump 是 JVM 的一个快照,记录了当前所有线程的状态,包括线程的 ID、名称、状态、锁信息等。通过分析 Thread Dump,...
ha456是一个IBM提供的轻量级heapdump分析工具,它可以帮助我们快速定位问题。 使用ha456.jar进行heapdump分析的步骤如下: 1. 将生成的heapdump.hprof文件与ha456.jar放在同一个目录下。 2. 运行heapdump.bat脚本...
在Java虚拟机(JVM)的运行过程中,有时会出现性能问题或者系统挂起的情况,这时候我们需要深入了解线程的运行状态,这就是"IBM thread dump文件分析工具"的作用所在。线程dump文件是JVM在特定时刻生成的一种快照,...
它通过分析JVM的堆转储(Heap Dump)文件,能帮助开发者深入理解内存分配情况,找出潜在的问题。 MAT的主要功能包括: 1. **内存泄漏检测**:MAT提供了一种名为"Leak Suspects"的报告,能够快速识别可能导致内存...
- **IBM Memory Analyzer (MAT)**: 这是IBM提供的专业heapdump分析工具,能够帮助开发者识别内存泄漏,计算对象引用链,提供内存占用报告等。 - **JConsole**: 虽然不是IBM官方工具,但也是Java标准监控工具之一,...