JNI C ++调试技术？

我有一个创建JVM并进行JNI调用的Linux C ++应用程序。我是JNI的新手，到目前为止，我发现开发过程中调试应用程序的唯一有效方法是反复试验。有什么技术可用来调试臭名昭著的“ Java Runtime Environment已检测到致命错误” Java VM崩溃？我怎么知道问题是我的代码还是真正的JVM错误？

通常，到目前为止，我所知道的显而易见的事情是：

在代码中，在继续进行操作之前，请始终检查从JNI调用返回的jobject，class和jmethodID值是否为NULL值。

在适当的地方调用env-> ExceptionCheck（）以确保没有未决的异常。

当前，我陷入了一个错误报告文件中的堆栈跟踪没有帮助的问题：

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002b137a99db59, pid=19977, tid=47362673452544
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode linux-amd64 )
# Problematic frame:
# V  [libjvm.so+0x40fb59]
  ...  ...
Stack: [0x00007fff1964f000,0x00007fff1974f000],  sp=0x00007fff1974e050,  free space=3fc0000000000000018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x40fb59]
V  [libjvm.so+0x3ecbe1]
C  [libDataFabric.so+0x1bb5b]  _Jv_JNIEnv::CallObjectMethod(__jobject*, _jmethodID*, ...)+0xe3
etc. ...

好的，所以我知道它在env-> CallObjectMethod（）中快要死了。在深入研究JVM代码之前，我检查了GDB中的所有参数，但没有看到任何明显的NULL或奇怪的值。当然，所有的JNI类（例如jobject）都是不透明的，因此我看不到它们的指针是否指向虚假数据或真实数据。

对于此类问题有任何提示/建议/想法吗？

好的，这就是我解决上面提到的问题的方式。虽然有些乏味，但经过足够的时间和精力，最终还是有所收获。

不要假设env-> CallMethod（jobj，meth_id，...）正在传递正确的值。如果这是崩溃的地方，则很有可能出现一些难以发现但根本的问题，例如传递的methodId与传递给CallObjectMethod（...）的jobject不匹配。我编写了一个简单的帮助程序方法std::string getClassInfo(JNIEnv* env, jclass aJavaClass)，该方法在类上获取“ toString”的MethodID，调用该方法，并将结果作为std :: string返回。那告诉我天气是我想的还是不是。

在JNI调用之间随意添加调试输出语句。特别是输出类名（例如通过上述方法）将帮助您确定天气对象是否符合您的想法。

确保您正在检查空的methodID，并在每个CallMethod（...）之后调用env-> ExceptionCheck（）。在CallMethod（...）之后检查null不会有帮助，因为JNI不知道null是否是有效的返回类型。

不要以为JNI在出现故障的第一个迹象时就会崩溃。在实际上崩溃之前，我实际上是通过几个JNI调用传递了错误的对象类型。请参阅＃3，以确保您尽早发现问题。