Question

我使用最新的Oracle Java Server JRE（1.8.0_91）在RHEL6上的Tomcat中运行了几个遗留Java Web应用程序。在过去的几周里，我在4个实例中总共发生了7次JVM崩溃，没有明显的时间模式或实例崩溃。为了找出原因，我启用了核心转储。

随着最新的崩溃产生了核心转储，但是我似乎无法通过标准Java工具获得任何信息，如jstack和jmap：

[root@c6e6c1b0b90e core-dump]# jstack -J-d64 /usr/jdk/jdk1.8.0_91/bin/java core.24182 
Attaching to core core.24182 from executable /usr/jdk/jdk1.8.0_91/bin/java, please wait...
Error attaching to core file: Can't attach to the core file
sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
    at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:286)
    at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:673)
    at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:611)
    at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:337)
    at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:304)
    at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:156)
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:191)
    at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
    at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
    at sun.tools.jstack.JStack.main(JStack.java:106)

我使用gdb取得了有限的成功，因为我可以检查回溯和帧，但是调试符号不可用，并且似乎没有太多可用信息指向问题的根源：

(gdb) bt
#0  0x00000036186325e5 in raise () from /lib64/libc.so.6
#1  0x0000003618633dc5 in abort () from /lib64/libc.so.6
#2  0x00007fe7462f8aa5 in os::abort(bool) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#3  0x00007fe746497593 in VMError::report_and_die() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#4  0x00007fe7462fe2cf in JVM_handle_linux_signal () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#5  0x00007fe7462f4a63 in signalHandler(int, siginfo*, void*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#6  <signal handler called>
#7  0x00007fe745f9d655 in G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#8  0x00007fe745f9e20b in G1ParScanThreadState::trim_queue() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#9  0x00007fe745f78af7 in G1ParEvacuateFollowersClosure::do_void() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#10 0x00007fe745f84623 in G1ParTask::work(unsigned int) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#11 0x00007fe7464b762f in GangWorker::loop() () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#12 0x00007fe7462f9f78 in java_start(Thread*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
#13 0x0000003618a07aa1 in start_thread () from /lib64/libpthread.so.0
#14 0x00000036186e8aad in clone () from /lib64/libc.so.6

(gdb) frame 7
#7  0x00007fe745f9d655 in G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*) () from /usr/jdk/jdk1.8.0_91/jre/lib/amd64/server/libjvm.so
(gdb)

所以我的问题是：

如何使用jstack / jmap分析核心转储？
我可以继续深入了解gdb吗？（这不是我的强项）
这对我来说就像一个JVM错误。我该如何确认？

感谢。

如何分析Java核心转储？

0 个答案: