I looked up everything but I don't understand why I receive a Fatal Signal 11.
Java side:
mRgba = inputFrame.rgba();
String nativeTesting = mNativeDetector.getFeatures(mRgba);
Log.e(TAG, nativeTesting);
// In another class
public String getFeatures(Mat image) {
Log.e("FRAME", " Rows:" +image.rows()); // This correctly returns the number of rows
String resultMsg = nativeFeatures(mNativeObj, image.getNativeObjAddr());
return resultMsg;
}
C++ side:
JNIEXPORT jstring JNICALL Java_com_example_myfacedetection_DetectionBasedTracker_nativeFeatures (JNIEnv* env, jclass, jlong image){
LOGD("NativeFeatures enter");
try {
Mat* frame = (Mat*) image;
// if (frame.empty()) // This also results in Fatal Signal
// LOGD("EMPTY FRAME");
LOGD("Size: %d", frame->rows);
}
catch(cv::Exception& e)
{
LOGD("nativeCreateObject caught cv::Exception: %s", e.what());
jclass je = env->FindClass("org/opencv/core/CvException");
if(!je)
je = env->FindClass("java/lang/Exception");
env->ThrowNew(je, e.what());
}
return (env)->NewStringUTF("Hello from JNI !");
}
I'm trying to calculate histogram, but any access to frame results in SegFault. What am I doing wrong?
The most likely problem here is that your native method declaration in Java (which you have not listed) does not match the signature in the JNI library.
You are calling it:
String resultMsg = nativeFeatures(mNativeObj, image.getNativeObjAddr())
So you probably have (otherwise javac would not compile):
static native String nativeDetect(long thiz, long image);
But in your JNI library you have:
JNIEXPORT jstring JNICALL Java_{snip}_nativeFeatures (JNIEnv* env, jclass, jlong image)
So you are passing mNativeObj into image, casting it to Mat and getting the SIGSEGV when actually trying to follow pointers.
To fix this problem update the method signature to match. For example, if you don't need access to the instance, make the static method a nativeDetect(long image) (and don't pass mNativeObj to it).
You are responsible for making sure that the method signatures match between your Java and C/C++ source files. Unless you have overloaded the native method (two signatures for the same name), the dynamic library loader is only looking for Java_{packageName}_{className}_{methodName} and can't tell that the number of arguments or types are mismatched.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments