Native library crashes on accessing the method with segmentation fault

748 views Asked by At

I have an Android application, where I added native library and make calls to JNI methods.

jbyteArray method1(JNIEnv *env, jobject obj, jbyteArray data) {
  LOGD("This method 1 should be printed")
  unsigned char *mdata   = (unsigned char *)env->GetByteArrayElements(data, 0);
  ... other logic. 

  if(mdata){
   env->ReleaseByteArrayElements(data, (jbyte *)mdata, 0);
  }
}

jbyteArray method2(JNIEnv *env, jobject obj, jbyteArray data,jint byteArraySize) {
   LOGD("This method 2 should be printed")
   unsigned char *tdata   = (unsigned char *)env->GetByteArrayElements(data, 0);
   ... other logic. 
   if(tdata){
     env->ReleaseByteArrayElements(data, (jbyte *)tdata, 0);
   }
  jbyteArray out = env->NewByteArray(byteArraySize);
  return out;

}

Here, the api call made to the method1 successful happens. Sometimes, on calling method 2, causes a fatal signal crash for segmentation fault and also teh point is
"This method 2 should be printed" doesn't get printed.

Kindly suggest the next steps see why the crash happened.

Crash:
- beginning of crash
09-25 07:04:56.603 17655 20657 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)... 
09-25 07:04:56.892 20677 20677 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x77df322000
09-25 07:04:57.162 20677 20677 F DEBUG   : backtrace:
09-25 07:04:57.162 20677 20677 F DEBUG   :       #00 pc 0000000000080ec8  /data/app/com.myapp.todo-KjB9VuHAYk0D1dMfxvPZ8w==/lib/arm64/mylib.so (BuildId: 524f4e07f077d0c3cb27f45b925cad005c414629)
09-25 07:04:57.162 20677 20677 F DEBUG   :       #01 pc 000000000009a868  /data/app/com.myapp.todo-KjB9VuHAYk0D1dMfxvPZ8w==/lib/arm64/mylib.so (BuildId: 524f4e07f077d0c3cb27f45b925cad005c414629)
09-25 07:04:57.162 20677 20677 F DEBUG   :       #02 pc 000000000009a868  /data/app/com.myapp.todo-KjB9VuHAYk0D1dMfxvPZ8w==/lib/arm64/mylib.so (BuildId: 524f4e07f077d0c3cb27f45b925cad005c414629)
09-25 07:04:57.162 20677 20677 F DEBUG   :       #03 pc 0000000000120f1c  /data/app/com.myapp.todo-KjB9VuHAYk0D1dMfxvPZ8w==/oat/arm64/base.odex (art_jni_trampoline+220)
09-25 07:04:57.163 20677 20677 F DEBUG   :       #04 pc 0000000000137334  /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: 2f49fcb66bab915227db68bcfc9afcde)
09-25 07:04:57.163 20677 20677 F DEBUG   :       #05 pc 0000000000145fec  /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244) (BuildId: 2f49fcb66bab915227db68bcfc9afcde)
09-25 07:04:57.163 20677 20677 F DEBUG   :       #06 pc 00000000002e2e18  /apex/com.android.runtime/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+384) (BuildId: 2f49fcb66bab915227db68bcfc9afcde)
09-25 07:04:57.163 20677 20677 F DEBUG   :       #07 pc 00000000002de078  /apex/com.android.runtime/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+892) (BuildId: 2f49fcb66bab915227db68bcfc9afcde)
09-25 07:04:57.163 20677 20677 F DEBUG   :       #08 pc 00000000005a7638  /apex/com.android.runtime/lib64/libart.so (MterpInvokeVirtualQuick+616) (BuildId: 2f49fcb66bab915227db68bcfc9afcde)
09-25 07:04:57.163 20677 20677 F DEBUG   :       #09 pc 0000000000135594  /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_virtual_quick+20) (BuildId: 2f49fcb66bab915227db68bcfc9afcde)
09-25 07:04:57.163 20677 20677 F DEBUG   :       #10 pc 0000000000940d3a  /data/app/com.myapp.todo-KjB9VuHAYk0D1dMfxvPZ8w==/oat/arm64/base.vdex (com.myclass.MyJavaClass.callMyMethod+210)
1

There are 1 answers

0
George Shakula On

"Sometimes" in most situations means that out-of-bounds memory writing happens. Verify that you are not doing it in method1. As for the next steps, I would start by compiling your library with debug symbols. Add this to the defaultConfig:

packagingOptions {
    doNotStrip '**/*.so'

    jniLibs {
        keepDebugSymbols += "**/*.so"
    }
}

ndk {
    debugSymbolLevel 'FULL'
}

This should give you a more explicit stack trace of the crash and allow debugging of the code.

Please update the question after you do this.