使用Java JNI时是否可以调试核心转储？

Question

我的应用程序主要是Java，但对于某些计算，使用的是C ++库。我们的环境是在RedHat 3（即将成为RedHat 5）上运行的Java 1.6。

我的问题是C 库不是线程安全的。为解决此问题，我们运行了多个单线程“工作者”进程，并由中央工作管理器（也用C

编写）为它们提供工作。我们的Java应用程序通过第三方产品调用C ++工作管理器。

由于各种原因，我们想重新编写C Work Manager和worker。我赞成使用Java编写所有代码，并在每个worker中使用JNI来调用C

库。

主要问题是如果C 库核心转储会发生什么。不幸的是，这很普遍，我们需要能够查看C 库中的哪一行导致了问题，例如，通过检查类似GDB的回溯。

我的同事认为，无法分析核心转储，因为GDB之类的工具无法理解Java生成的核心文件。

我希望它们是错误的，但是在进一步推动我的想法之前，我需要确定。

分析Java / JNI产生的核心转储的最佳方法是什么？

Answer 1

就在这里。每次JVM由于JNI部分中的SIGSEGV崩溃时，您都会在$ JAVA_HOME /
bin目录中获得一个带有核心转储的文件。通常将其命名为hs_err_PID.log。

您可以在此处和此处获取更多信息。这是一个有点相关的stackoverflow问题。