使用Java JNI可以调试核心转储？ [英] Is it possible to debug core dumps when using Java JNI?
问题描述
我的问题是C ++库不是线程安全的。为了解决这个问题，我们运行多个单线程的工作者进程，并通过一个也以C ++编写的中央工作管理器进行工作。我们的Java应用程序通过第三方产品调用C ++工作管理器。
由于各种原因，我们要重写C ++工作管理器和工作人员。我赞成用Java编写它们，在每个工作人员中使用JNI调用C ++库。
主要问题是如果C ++库内核转储。不幸的是，这是很常见的，我们需要能够看到我们的C ++库中的哪一行导致了这个问题。通过检查像GDB这样的回溯。
我的同事认为，分析核心转储是不可能的，因为GDB这样的工具不了解由Java。
我希望他们错了，但是在进一步推动我的想法之前，我需要确定。
分析Java / JNI生成的核心转储的最佳方法是什么？
是的，有。每次JVM由于JNI部分中的SIGSEGV而崩溃，您将在$ JAVA_HOME / bin目录中获取一个包含核心转储的文件。它通常命名为hs_err_PID.log。
您可以获得更多信息这里和这里。 这里是一个有点相关的stackoverflow问题。
My application is mostly Java but, for certain calculations, uses a C++ library. Our environment is Java 1.6 running on RedHat 3 (soon to be RedHat 5).
My problem is that the C++ library is not thread-safe. To work around this, we run multiple, single-threaded "worker" processes and give them work to do from a central Work Manager, also written in C++. Our Java application calls the C++ Work Manager via a third-party product.
For various reasons, we want to re-write the C++ Work Manager and workers. I'm in favour of writing them all in Java, using JNI in each worker to call the C++ library.
The main problem is what happens if the C++ library core dumps. Unfortunately, this is quite common, and we need to be able to see which line in our C++ library caused the problem, e.g. by examining a backtrace in something like GDB.
My colleagues believe that it will be impossible to analyse the core dumps, because tools like GDB don't understand core files produced by Java.
I hope that they're wrong, but I need to be sure before pushing my ideas further.
What is the best way to analyse a core dump produced from Java/JNI?
Yes, there is. Everytime JVM crashes because of a SIGSEGV in the JNI part, you'll get a file with core dump in $JAVA_HOME/bin directory. It usually name hs_err_PID.log.
You can get more info here, and here. Here is a somewhat related stackoverflow question.
这篇关于使用Java JNI可以调试核心转储？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
