如何为 JNI 代码生成故障转储答案

【问题标题】：How to generate crash dumps for JNI code如何为 JNI 代码生成故障转储
【发布时间】：2014-12-30 05:09:12
【问题描述】：

大家，

假设我在 Windows 中有一个简单的 JNI 程序：

int* p = NULL;
*p = 5;

当从 JVM 运行它时，与普通的 C++ 应用程序不同，JVM 会很好地捕获此类硬异常并进行一些清理工作。

这里的问题是它也阻止了我在那里生成崩溃转储，虽然有一个 JVM 选项：-XX:OnError，但此时生成的核心转储远离犯罪现场，因此难以调试。

JVM 使用 SEH 包装每个 Java 线程：

__try
{
    thread.run()
}
__except(topLevelExceptionFilter())
{
}

导致访问冲突的 JNI 代码发生在 thread.run 中，但在 topLevelExceptionFilter 中处理，它已经在其他地方。

你有什么建议吗？

谢谢。

【问题讨论】：

标签： java java-native-interface dump

【解决方案1】：

您可以使用 OnError 设置来启动本机调试器，如下所示：

http://download.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/clopts.html#gbmum

java -XX:OnError="gdb - %p" MyApplication

适用于 Windows

JDK7 还有一个-XX:+ShowMessageBoxOnError 或-XX:+UseOSErrorReporting 选项，不确定它是否适用于Linux 核心转储，它应该适用于Windows 和默认的操作系统调试器（DrWatson）。见http://blogs.oracle.com/poonam/entry/more_on_windows_crash_dumps

【讨论】：

谢谢，是的，UseOSErrorReporting 在 Windows 中有效；在linux中，coredump是默认生成的，不需要额外的选项。

【解决方案2】：

core 是一个 C++ 故障转储...您没有 Java 提供的便利设施来使其更易于使用。如果您编译您的本机代码以保留符号（理想情况下不进行优化），您可以使用 gdb 或其他调试器对其进行分析，并在故障点获取堆栈跟踪，以及读取变量等。

core dumps generated at this point is far from the crime scene thus hard to debug -- 核心转储根本不是“远离犯罪现场”，它们完全涵盖了所谓的犯罪现场。您认为它们难以调试的唯一原因是它是您尚未学会的东西......但它们绝对是这项工作的正确工具。

【讨论】：

关键是JVM会捕获这样的硬异常（访问冲突），因此您没有机会在真正的错误时生成核心转储。异常处理机制使代码执行跳转到 JVM 的异常处理程序，这是您获得核心转储的地方。
“这是你还没学过的东西” - 你能提供更多关于这方面的信息吗？谢谢。
实际上，导致核心转储的问题一定不是出现在 JVM 的异常处理程序中——如果是，您可以尝试/捕获它。当操作系统检测到应用程序存在严重问题并因此向其发送由进程的默认信号处理程序而不是自定义信号处理程序捕获的信号时，就会发生核心转储......自定义处理程序可以在没有核心转储的情况下终止进程，或者在某些情况下，[通过事先计划和使用 setjmp() 和 longjmp()] 从中恢复。
http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php 提供了开始使用核心转储分析的教程。请注意，如果您的本机库未使用 -g 编译和链接，您的分析的实用性将受到影响。

【解决方案3】：

在 linux 中使用 ulimit -c unlimited 来生成核心转储然后用gdb用java进程调试core文件。

【讨论】：