如何在运行我的代码时调试JVM中发生的Segfaults？

Question

我的Java应用程序已开始定期崩溃,包括SIGSEGV和堆栈数据转储以及文本文件中的大量信息.

我在gdb中调试了C程序,并且已经从IDE调试了Java代码.我不确定如何在正在运行的Java程序中处理类似C的崩溃.

我假设我不是在看这里的JVM错误.其他Java程序运行得很好,Sun的JVM可能比我的代码更稳定.但是,我不知道如何使用Java代码导致段错误.肯定有足够的可用内存,当我上次检查分析器时,堆使用率约为50%,偶尔会出现80%左右的峰值.我可以调查任何启动参数吗？在接近像这样的bug时,什么是好的清单？

虽然我不能够可靠地再现事件,但它似乎也不是完全随机发生的,所以测试并非完全不可能.

ETA:一些血腥的细节

(我正在寻找一种通用方法,因为实际问题可能非常具体.但是,我已经收集了一些信息并且可能有一些价值.)

不久之前,升级我的CI服务器之后遇到了类似的问题(详见此处),但是这次修复(设置-XX:MaxPermSize)没有帮助.

进一步的调查显示,在崩溃日志文件中,标记为"当前线程"的线程永远不是我的,但任何一个称为"VMThread"或称为"GCTaskThread" - 我是后者,它还标有注释"(已退出)",如果是前者,则GCTaskThread不在列表中.这让我想到问题可能是在GC操作结束时.

Answer 1

我假设我不是在看这里的JVM错误.其他Java程序运行得很好,Sun的JVM可能比我的代码更稳定.

我不认为你应该做出这样的假设.在不使用JNI的情况下,您不应该编写导致SIGSEGV的Java代码(尽管我们知道它发生了).我的观点是,当它发生时,它要么是JVM中的一个错误(不是闻所未闻),要么是某些JNI代码中的错误.如果你自己的代码中没有任何JNI,那并不意味着你没有使用某个库,所以请寻找它.当我之前看到这种问题时,它出现在图像处理库中.如果罪魁祸首不在您自己的JNI代码中,您可能无法"修复"该错误,但您仍然可以解决它.

首先,您应该在同一平台上获得备用JVM并尝试重现它.您可以尝试其中一种替代方案.

如果你无法重现它,它可能是一个JVM错误.从那里,您可以使用您知道的有关如何重现它的任务来命令特定JVM或搜索错误数据库,也可以获得建议的解决方法.(即使你可以重现它,许多JVM实现只是对Oracle的Hotspot实现的调整,所以它可能仍然是一个JVM错误.)

如果您可以使用备用JVM重现它,则可能是您遇到了一些JNI错误.查看您正在使用的库以及它们可能正在进行的本机调用.有时,对于相同的库或替代库,可以使用替代的"纯Java"配置或jar文件来执行几乎相同的操作.

祝好运!

Answer 2

除非您有本机代码,否则以下内容几乎肯定无用.但是,这里有.

1. 在java调试器中启动java程序,在可能的sigsegv之前使用断点.
2. 使用ps命令获取java的processid.
3. gdb/usr/lib/jvm/sun-java6/bin/java processid
4. 确保将gdb'handr'命令设置为在SIGSEGV上停止
5. 从断点继续java调试器.
6. 等待爆炸.
7. 使用gdb进行调查

如果你真的设法让JVM在没有你自己的本机代码的情况下使用sigsegv,你就不太可能对下一步会看到什么有任何意义,你能做的最好就是将测试用例推到bug上报告.