SIGSEGV in gmsec::api::jni::convertEvent

[wardev]

Ran the Java interface to GMSEC API 4.6-RH7 with the -Xcheck:jni to make sure it is making valid JNI calls. Used a ConnectionManager to make a request with a call back. It turns out that GMSEC API was not correctly using JNI.

This is the output from -Xcheck:jni:

WARNING in native method: JNI call made with exception pending
FATAL ERROR in native method: Bad global or local ref passed to JNI

The is the stack of the thread that caused the seg fault:

Stack: [0x00007f3145cf7000,0x00007f31464f7000],  sp=0x00007f31464f5860,  free space=8186k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x37bc7]  abort+0x297
V  [libjvm.so+0x71aa8b]  jniCheck::validate_handle(JavaThread*, _jobject*)+0xab
V  [libjvm.so+0x71ae25]  jniCheck::validate_class(JavaThread*, _jclass*, bool) [clone .constprop.176]+0x15
V  [libjvm.so+0x71be15]  checked_jni_GetStaticFieldID+0x75
C  [libgmsec_jni.so+0xb7d30]  JNIEnv_::GetStaticFieldID(_jclass*, char const*, char const*)+0x38
C  [libgmsec_jni.so+0xba67f]  gmsec::api::jni::convertEvent(JNIEnv_*, gmsec::api::Connection::ConnectionEvent)+0x109
C  [libgmsec_jni.so+0xf54f2]  gmsec::api::jni::CxxConnMgrReplyCallbackProxy::onEvent(gmsec::api::mist::ConnectionManager&, gmsec::api::Status const&, gmsec::api::Connection::ConnectionEvent)+0x3bc
C  [libGMSECAPI.so+0x37e1c5]  gmsec::api::mist::internal::CMReplyCallback::onEvent(gmsec::api::Connection&, gmsec::api::Status const&, gmsec::api::Connection::ConnectionEvent)+0x45
C  [libGMSECAPI.so+0x344cca]  gmsec::api::internal::InternalConnection::replyEvent(gmsec::api::ReplyCallback*, gmsec::api::Status const&, gmsec::api::Connection::ConnectionEvent)+0x68
C  [libGMSECAPI.so+0x36742f]  gmsec::api::internal::RequestShared::sendRequests()+0x20d
C  [libGMSECAPI.so+0x367008]  gmsec::api::internal::RequestShared::run()+0x3cc
C  [libGMSECAPI.so+0x366af0]  gmsec::api::internal::runRequestThread(gmsec::api::util::StdSharedPtr<gmsec::api::internal::RequestShared>)+0x20
C  [libGMSECAPI.so+0x34d465]  gmsec::api::util::StdThread::FunctionInvoker<void (*)(gmsec::api::util::StdSharedPtr<gmsec::api::internal::RequestShared>), gmsec::api::util::StdSharedPtr<gmsec::api::internal::RequestShared> >::_invoke()+0x35
C  [libGMSECAPI.so+0x3e3210]  gmsec::api::util::StdThread::Invoker::invoke()+0xa6
C  [libGMSECAPI.so+0x3e1c3f]  gmsec::api::util::StdThread::process0(void*)+0x21
C  [libpthread.so.0+0x7ea5]  start_thread+0xc5

[wardev]

Upon further investigation it seems that the problem is two fold.

First the code at [1] does not check the return value of FindClass before using it in another function call at [2], which causes the segfault. Specifically, FindClass will return 0 if it doesn't find the class and GetStaticFieldID will segfault if the class is null.

As a Java developer, I would expect that if a class cannot be found then a ClassNotFoundException will be thrown.

Second the code at [1] does not use the correct ClassLoader. Quoting from [3], "FindClass locates the class loader associated with the current native method; that is, the class loader of the class that declared the native method." If " there is no current native method or its associated class loader [then] in that case, the result of ClassLoader.getSystemClassLoader is used." Looking at the back trace there is no Java frames that FindClass can retrieve the ClassLoader from, so it will use the system ClassLoader, which does not contain the requested class.

As a Java developer, I would expect that if a class needs to be loaded to service a request then the ClassLoader of the class making the request will be used, or the ClassLoader of the callback.

As a Java developer, I expect the system ClassLoader will never be used.

Finally, one more request. Please include debugging symbols in your releases. Then it will be much easier to find the bugs in the native code as I won't have to disassemble it first.

[1]

GMSEC_API/java/src_4x/gmsecJNI_Jenv.cpp

Line 358 in 660629d

jclass clazz = jenv->FindClass("gov/nasa/gsfc/gmsec/api/Connection$ConnectionEvent");

[2]

GMSEC_API/java/src_4x/gmsecJNI_Jenv.cpp

Line 377 in 660629d

jfieldID jField = jenv->GetStaticFieldID(clazz, eventString, "Lgov/nasa/gsfc/gmsec/api/Connection$ConnectionEvent;");

[3] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#FindClass

[wardev]

Looking through the code a bit more, it seems that [4] has the right idea - to initialize all classes when the JNI interface is initialized. Then there will be Java frame on the stack, so FindClass will use that ClassLoader. It seems the call to FindClass should be moved form Jenv to Cache. And any other calls to load GMSEC API Java classes should be done in Cache as well so they are loaded when the JNI interface is initialized.

[4]

GMSEC_API/java/src_4x/gmsecJNI_Init.cpp

Line 39 in 660629d

Cache::getCache().initialize(jenv);