我有一个Linux C++应用程序,它创建一个JVM并使JNI调用。我刚接触JNI,到目前为止,我发现在开发过程中调试应用程序的唯一有效方法是通过尝试和错误。有什么技术可以用来调试臭名昭著的“致命错误被Java运行时环境检测到”Java虚拟机崩溃?我如何知道问题是我的代码还是真正的JVM bug?

总的来说,到目前为止我所知道的最明显的事情是:

在代码中,在继续之前,始终检查JNI调用返回的jobject、class和jmethodid值是否为空值。

在适当的地方调用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中的所有参数,但没有看到任何明显的空值或奇怪的值。当然,所有的JNI类,比如Jobject,都是不透明的,所以我看不出它们的指针指向的是伪造的还是真实的数据。

对于这类问题有什么建议吗?