如何在 Linux 上调试原生 Java 崩溃？答案

【问题标题】：How to debug a native Java crash on Linux?如何在 Linux 上调试原生 Java 崩溃？
【发布时间】：2010-12-23 17:49:36
【问题描述】：

我已经看到 this question 和 this article 了解如何调试原生 Java 崩溃。这篇文章是关于 Windows 的。 Linux 上有哪些等效的调试辅助工具？

注意：我所拥有的只是来自该领域用户的崩溃日志。我无法访问发生崩溃的机器。

更新：我很确定崩溃是由于我们拥有的 JNI 代码造成的。我从来没有暗示是 JVM 本身有问题。

根据请求，这里是崩溃转储（或符合 30K 堆栈溢出限制的尽可能多的内容）：

# # Java Runtime Environment 检测到意外错误： # # SIGSEGV (0xb) at pc=0x06300e76, pid=9983, tid=4106996592 # # Java VM：Java HotSpot(TM) Client VM（1.6.0_03-b05混合模式，共享） # 有问题的框架： #V [libjvm.so+0x300e76] # # 如果您想提交错误报告，请访问： # http://java.sun.com/webapps/bugreport/crash.jsp # - - - - - - - - 线 - - - - - - - - 当前线程 (0x0922e000): VMThread [id=9985] siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000008 寄存器： EAX=0x00000008，EBX=0x88a829b3，ECX=0x88a829b0，EDX=0xa7d6c1dc ESP=0xf4cbba5c，EBP=0xf4cbba68，ESI=0xa7d6d1d8，EDI=0x00000404 EIP=0x06300e76，CR2=0x00000008，EFLAGS=0x00010202 栈顶：(sp=0xf4cbba5c) 0xf4cbba5c: a7d6c1c8 0920cc30 aa0de5c0 f4cbba98 0xf4cbba6c: 063517d7 cf8f2a20 a7d6c1c8 0920cc30 0xf4cbba7c：0920cc30 00000000 00000000 6d224c40 0xf4cbba8c: 00000001 f4cbbbb0 0920b440 f4cbbab8 0xf4cbba9c: 061dd4df 0920cc30 f4cbbb10 f4cbbac8 0xf4cbbaac: 0633cb7e 0643b5b8 f4492968 f4cbbad8 0xf4cbbabc: 061dcd68 f4cbbaf0 0920cc30 f4cbbaf8 0xf4cbbacc: 061df31e f4cbbb10 d4cbcc2c f4cbbb08 说明：（pc=0x06300e76） 0x06300e66：82 39 f2 73 34 90 8d 74 26 00 8b 02 85 c0 74 22 0x06300e76：8b 18 80 3d 45 10 42 06 00 74 0c 89 d8 31 c9 83 堆栈：[0xf4c3c000,0xf4cbd000)，sp=0xf4cbba5c，可用空间=510k 本机帧：（J=编译的 Java 代码，j=解释的，Vv=VM 代码，C=本机代码） V [libjvm.so+0x300e76] V [libjvm.so+0x3517d7] V [libjvm.so+0x1dd4df] V [libjvm.so+0x1dcd68] V [libjvm.so+0x1dc3cc] V [libjvm.so+0x1d4c52] V [libjvm.so+0x1d32cc] V [libjvm.so+0x1d4229] V [libjvm.so+0x1dc82a] V [libjvm.so+0x1d1d34] V [libjvm.so+0x186125] V [libjvm.so+0x1d20bc] V [libjvm.so+0x3b2cbe] V [libjvm.so+0x3c5037] V [libjvm.so+0x3c46bc] V [libjvm.so+0x3c488a] V [libjvm.so+0x3c446f] V [libjvm.so+0x30b719] C [libpthread.so.0+0x5cb2] VM_Operation (0xf2b60728)：用于分配的生成集合，模式：安全点，由线程 0x09449c00 请求 - - - - - - - - 过程 - - - - - - - - Java 线程：（=> 当前线程） 0x092afc00 JavaThread "RawImageCache" 守护进程 [_thread_blocked, id=10026] 0xf37d1000 JavaThread "TimerQueue" 守护进程 [_thread_blocked, id=10022] 0x09410000 JavaThread "SunTileScheduler0Standard7" 守护进程 [_thread_blocked, id=10021] 0x0940f000 JavaThread "SunTileScheduler0Standard6" 守护进程 [_thread_blocked, id=10020] 0x0946fc00 JavaThread "SunTileScheduler0Standard5" 守护进程 [_thread_blocked, id=10019] 0x0946e800 JavaThread "SunTileScheduler0Standard4" 守护进程 [_thread_blocked, id=10018] 0x0946d400 JavaThread "SunTileScheduler0Standard3" 守护进程 [_thread_blocked, id=10017] 0x0946c000 JavaThread "SunTileScheduler0Standard2" 守护进程 [_thread_blocked, id=10016] 0x0946ac00 JavaThread "SunTileScheduler0Standard1" 守护进程 [_thread_blocked, id=10015] 0x0946a000 JavaThread "SunTileScheduler0Standard0" 守护进程 [_thread_blocked, id=10014] 0x0944a800 JavaThread“图像列表轮询器”[_thread_blocked，id=10012] 0x09449c00 JavaThread“图像任务队列”[_thread_blocked，id=10011] 0xf37e3c00 JavaThread "Laf-Widget 淡化跟踪器" [_thread_blocked, id=10010] 0x094abc00 JavaThread "FileCacheMonitor" 守护进程 [_thread_blocked, id=10009] 0xf37e3800 JavaThread "DestroyJavaVM" [_thread_blocked, id=9984] 0xf37ee400 JavaThread "Thread-6" 守护进程 [_thread_blocked, id=10006] 0xf3a7c800 JavaThread "DirectoryMonitor.MonitorThread" 守护进程 [_thread_blocked, id=10005] 0xf3a73800 JavaThread "AWT Watchdog" 守护进程 [_thread_blocked, id=10004] 0xf3adb800 JavaThread "TileReaper" 守护进程 [_thread_blocked, id=10003] 0x093c3c00 JavaThread“进程收割者”守护进程 [_thread_in_native, id=10001] 0x093ac800 JavaThread "Timer-0" 守护进程 [_thread_blocked, id=9999] 0x093a8c00 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=9997] 0x093a8000 JavaThread "AWT-Shutdown" [_thread_blocked, id=9996] 0x09378c00 JavaThread "AWT-XAWT" 守护进程 [_thread_blocked, id=9994] 0x09368400 JavaThread "Java2D Disposer" 守护进程 [_thread_blocked, id=9993] 0x09350000 JavaThread "Thread-1" 守护进程 [_thread_blocked, id=9992] 0x0923b400 JavaThread“低内存检测器”守护进程 [_thread_blocked, id=9990] 0x09239c00 JavaThread "CompilerThread0" 守护进程 [_thread_blocked, id=9989] 0x09238800 JavaThread“信号调度程序”守护进程 [_thread_blocked, id=9988] 0x09230800 JavaThread“终结器”守护进程 [_thread_blocked, id=9987] 0x0922f400 JavaThread“引用处理程序”守护进程 [_thread_blocked，id=9986] 其他主题： =>0x0922e000 VMThread [id=9985] 0x09245000 WatcherThread [id=9991] VM 状态：在安全点（正常执行） VM Mutex/Monitor 当前由一个线程拥有：([mutex/lock_event]) [0x09205178/0x092051a0] Threads_lock - 所有者线程：0x0922e000 [0x09205638/0x09205650] Heap_lock - 所有者线程：0x09449c00 堆 def 新一代总 83968K, 使用 9280K [0x55600000, 0x5b110000, 0x5ec40000) 伊甸园空间 74688K, 0% 已使用 [0x55600000, 0x55600000, 0x59ef0000) 从空间 9280K, 100% 使用 [0x5a800000, 0x5b110000, 0x5b110000) 到空间 9280K，使用 0% [0x59ef0000, 0x59ef0000, 0x5a800000) 终身代总计 1233640K，已使用 1233529K [0x5ec40000, 0xaa0fa000, 0xcf800000) 空间 1233640K, 99% 已使用 [0x5ec40000, 0xaa0de5c0, 0x8b4af400, 0xaa0fa000) 压缩 perm gen 总计 13312K，使用 13175K [0xcf800000, 0xd0500000, 0xd3800000) 空间 13312K, 98% 已使用 [0xcf800000, 0xd04ddd70, 0xd04dde00, 0xd0500000) ro 空间 8192K，已使用 69% [0xd3800000, 0xd3d8f608, 0xd3d8f800, 0xd4000000) rw 空间 12288K, 57% 已使用 [0xd4000000, 0xd46eee98, 0xd46ef000, 0xd4c00000) 动态库： [剪辑] 虚拟机参数： jvm_args：-Dinstall4j.jvmDir=/home/berbmit/bin/LightZone/jre -Dinstall4j.appDir=/home/berbmit/bin/LightZone -Dexe4j.moduleName=/home/berbmit/bin/LightZone/LightZone -Dcom.lightcrafts。 licensetype=ESD -Xmx2000000k java_command: com.install4j.runtime.Launcher 启动 com.lightcrafts.platform.linux.LinuxLauncher true false /home/berbmit/bin/LightZone/LightZone.log /home/berbmit/bin/LightZone/LightZone.log false true false true true -1 -1 20 20 Arial 0,0,0 8 500 20 40 Arial 0,0,0 8 500 -1 启动器类型：SUN_STANDARD 环境变量： PATH=/home/berbmit/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games 用户名=berbmit LD_LIBRARY_PATH=/home/berbmit/bin/LightZone/jre/lib/i386/client:/home/berbmit/bin/LightZone/jre/lib/i386:/home/berbmit/bin/LightZone/jre/../lib/ i386:/home/berbmit/bin/LightZone/.: SHELL=/bin/bash 显示=：0.0 信号处理器： SIGSEGV：[libjvm.so+0x3b29c0]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGBUS：[libjvm.so+0x3b29c0]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGFPE：[libjvm.so+0x309ec0]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGPIPE：SIG_IGN，sa_mask[0]=0x00000000，sa_flags=0x00000000 信号：[libjvm.so+0x309ec0]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGUSR1：SIG_DFL，sa_mask[0]=0x00000000，sa_flags=0x00000000 SIGUSR2：[libjvm.so+0x30bef0]，sa_mask[0]=0x00000000，sa_flags=0x10000004 SIGHUP：[libjvm.so+0x30b910]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGINT：[libjvm.so+0x30b910]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGQUIT：[libjvm.so+0x30b910]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGTERM：[libjvm.so+0x30b910]，sa_mask[0]=0x7ffbfeff，sa_flags=0x10000004 SIGUSR2：[libjvm.so+0x30bef0]，sa_mask[0]=0x00000000，sa_flags=0x10000004 - - - - - - - - 系统 - - - - - - - - 操作系统：挤压/sid uname:Linux 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 11:55:36 UTC 2010 x86_64 libc:glibc 2.12.1 NPTL 2.12.1 rlimit：堆栈 8192k，核心 0k，NPROC 无穷大，NOFILE 1024，AS 无穷大平均负载：0.67 0.54 0.36 CPU：共 8 个（每个 cpu 8 个内核，每个内核 2 个线程）系列 6 型号 10 步进 5、cmov、cx8、fxsr、mmx、sse、sse2、sse3、ssse3、ht 内存：4k页面，物理8191552k（3359308k免费），交换1016828k（1016828k免费） vm_info：适用于 linux-x86 的 Java HotSpot(TM) 客户端 VM (1.6.0_03-b05)，由“java_re”和 gcc 3.2.1-7a（J2SE 版本）于 2007 年 9 月 24 日 22:45:46 构建

【问题讨论】：

我无法评论如何调试，但与普遍看法相反，JVM 崩溃非常普遍。这是一个稳定可靠的系统上的可重现系统，正常运行时间通常达到 6 个月（这是我的工作站，所以我不介意每六个月重新启动一次，当出现中断时；）stackoverflow.com/questions/2299250
那是你链接到那里的一篇很棒的文章：weblogs.java.net/blog/kohsuke/archive/2009/02/… 而不是采取 “JVM 不要崩溃，你的硬件有问题” 种下意识的方法，这家伙确实很好地解释了如何深入了解机器代码，并证明 JVM 确实有问题。对您的问题 +1，不要注意那些会在这里说 “JVM 不再崩溃”的人。
除非崩溃中包含敏感信息，否则将崩溃转储文本添加到您的问题中。它讲述了很多关于发生的事情。
@SpoonBender。根据我的经验，JVM 崩溃与 JNI 密切相关。
正如@Thorbjørn Ravn Andersen 提到的，从数据转储开始。首先在谷歌上搜索它，看看它是否是一个报告但是（我曾经能够让 Java 1.4.2 经常因为一个已知的错误而崩溃，我不得不解决这个问题）。如果你空了，把垃圾堆带到这里。

标签： java linux debugging jvm

【解决方案1】：

除非您的 JNI 库损坏了随机的内存区域（这极难调试），否则 libjvm 崩溃的最可能原因是 JVM 中的错误。鉴于当前版本是 Java 6 update 23，而您拥有 Java 6 update 3，升级是我会尝试的第一件事。

顺便说一句：你似乎有一个 64 位操作系统，你可能想尝试 64 位 Java。

BTW2：您可以将 -Xmx2000000k 写为 -mx2g。无论如何，8 GB 机器上的默认最大值应该是 2 GB 左右。

【讨论】：

+1 表示首先尝试新的 JVM，特别是如果此崩溃可重复且易于重现。升级并查看它是否发生可能比在较旧的 JVM 中查找原因更快。

【解决方案2】：

我期待崩溃转储中的 JNI 调用，但这似乎不是原因，而是 pthreads 库中的错误。

我不记得 pthreads 库是否必须由底层平台提供，或者它被烘焙到 JRE 中，但我建议您确保您在官方支持的 Linux 平台之一上运行，如果不是，那么强烈考虑切换。

【讨论】：

【解决方案3】：

你真的需要 -Xmx2000000k 吗？看起来你只使用了大约 84MB。

我的经验是，无论如何，在 32 位进程空间中，您确实无法可靠地超过 1700MB 堆。因此，该设置可能会导致此问题。

【讨论】：