我的应用程序主要是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产生的核心转储的最佳方法是什么?
就在这里。每次JVM由于JNI部分中的SIGSEGV崩溃时,您都会在$ JAVA_HOME / bin目录中获得一个带有核心转储的文件。通常将其命名为hs_err_PID.log。
您可以在此处和此处获取更多信息。这是一个有点相关的stackoverflow问题。