JNI - 應用程序崩潰

這是與NDK和Android SDK的問題。目前，我的C代碼正在調用Java中定義的方法。這個方法叫做callFromNDK（）。JNI - 應用程序崩潰

在這個方法中，我引用了媒體播放器的實例，以發揮短的測試音。 callFromNDK（）每2秒調用一次。測試音本身是一秒鐘。

我看到的是一個（SIGSEGV），代碼1（SEGV_MAPERR），有時還有故障地址fffffff4。

我想知道如果發生這種情況，因爲媒體播放器的實例是在不同的上下文，它在漸漸習慣了一個創造出來的？

下面是相關的代碼段[爪哇文件]

public class Canvastutorial extends Activity { 
    private static MediaPlayer mediaPlayer = null; 
    public void callFromNDK() { 
     if (mediaPlayer != null) { 
      mediaPlayer.start(); 
     } 
    } 

    @Override 
    public void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     mediaPlayer = MediaPlayer.create(getApplicationContext(), R.raw.audioclip); 
     mediaPlayer.setLooping(false); 
    } 

    @Override 
    protected void onDestroy() { 
     mediaPlayer.release(); 
     mediaPlayer = null; 
     System.gc(); 
     super.onDestroy(); 
    } 

    @Override 
    protected void onPause() { 
     stopAndPrepare(); 
     super.onPause(); 
    } 

    private void stopAndPrepare() { 
      mediaPlayer.stop(); 
      try { 
       mediaPlayer.prepare(); 
      } catch (IllegalStateException e) { 
       e.printStackTrace(); 
      } catch (IOException e) { 
       e.printStackTrace(); 
      } 
      mediaPlayer.seekTo(0); 
    } 
}

的logcat的是如以下時應用程序崩潰：

04-27 10:42:13.228: I/DEBUG(8926): Build fingerprint: 'google/passion/passion:2.3.6/GRK39F/189904:user/release-keys' 
04-27 10:42:13.228: I/DEBUG(8926): pid: 10362, tid: 11222 >>> <package_name> <<< 
04-27 10:42:13.228: I/DEBUG(8926): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr fffffff4 
04-27 10:42:13.238: I/DEBUG(8926): r0 4214cdc0 r1 00000000 r2 00000000 r3 0000ce68 
04-27 10:42:13.238: I/DEBUG(8926): r4 44628398 r5 00000000 r6 4472fbd8 r7 0000000e 
04-27 10:42:13.238: I/DEBUG(8926): r8 80018000 r9 00000000 10 00000000 fp 800a5368 
04-27 10:42:13.238: I/DEBUG(8926): ip 00000000 sp 4472fb88 lr 8001d084 pc 8001d090 cpsr 60000010 
04-27 10:42:13.238: I/DEBUG(8926): d0 00650072006800b8 d1 00000044bed7f457 
04-27 10:42:13.238: I/DEBUG(8926): d2 0069006400650052 d3 004d0049002e0040 
04-27 10:42:13.238: I/DEBUG(8926): d4 0061006900640065 d5 00790061006c0050 
04-27 10:42:13.238: I/DEBUG(8926): d6 0065005300720065 d7 0063006900760072 
04-27 10:42:13.238: I/DEBUG(8926): d8 0000000000000000 d9 0000000042ba56de 
04-27 10:42:13.238: I/DEBUG(8926): d10 0000000000000000 d11 0000000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d12 0000000000000000 d13 0000000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d14 0000000000000000 d15 0000000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d16 0000000000000001 d17 c053000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d18 0000000000000000 d19 0000000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d20 3ff0000000000000 d21 8000000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d22 0000000000000000 d23 ff00000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d24 ff00000000000000 d25 ff00000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d26 0100010001000100 d27 0100010001000100 
04-27 10:42:13.238: I/DEBUG(8926): d28 0100010001000100 d29 3ff0000000000000 
04-27 10:42:13.238: I/DEBUG(8926): d30 0000000000000000 d31 3ff0000000000000 
04-27 10:42:13.238: I/DEBUG(8926): scr 60000012 
04-27 10:42:13.328: I/DEBUG(8926):   #00 pc 0001d090 /system/lib/libdvm.so 
04-27 10:42:13.328: I/DEBUG(8926):   #01 pc 000220e4 /system/lib/libdvm.so 
04-27 10:42:13.328: I/DEBUG(8926):   #02 pc 00020fdc /system/lib/libdvm.so 
04-27 10:42:13.328: I/DEBUG(8926):   #03 pc 0005fc40 /system/lib/libdvm.so 
04-27 10:42:13.328: I/DEBUG(8926):   #04 pc 0004cff8 /system/lib/libdvm.so 
04-27 10:42:13.328: I/DEBUG(8926):   #05 pc 00001590 /data/data/<package_name>/lib/libtest-jni.so 
04-27 10:42:13.328: I/DEBUG(8926):   #06 pc 000016ca /data/data/<package_name>/lib/libtest-jni.so 
04-27 10:42:13.328: I/DEBUG(8926):   #07 pc 000118e4 /system/lib/libc.so 
04-27 10:42:13.328: I/DEBUG(8926):   #08 pc 000114b0 /system/lib/libc.so 
04-27 10:42:13.328: I/DEBUG(8926): code around pc: 
04-27 10:42:13.328: I/DEBUG(8926): 8001d070 fa0108cc ea000017 e3a00001 e3a09000 
04-27 10:42:13.328: I/DEBUG(8926): 8001d080 ebffff72 e2450014 e5905000 e5909004 
04-27 10:42:13.328: I/DEBUG(8926): 8001d090 e515200c e5963018 e3520000 1592a000 
04-27 10:42:13.328: I/DEBUG(8926): 8001d0a0 e3a01000 0affff8a e1f970b6 e5862010 
04-27 10:42:13.328: I/DEBUG(8926): 8001d0b0 e59a1028 e5835028 e590a010 e1a04009 
04-27 10:42:13.328: I/DEBUG(8926): code around lr: 
04-27 10:42:13.328: I/DEBUG(8926): 8001d064 e088f30c e1a01000 e5960018 fa0108cc 
04-27 10:42:13.328: I/DEBUG(8926): 8001d074 ea000017 e3a00001 e3a09000 ebffff72 
04-27 10:42:13.328: I/DEBUG(8926): 8001d084 e2450014 e5905000 e5909004 e515200c 
04-27 10:42:13.328: I/DEBUG(8926): 8001d094 e5963018 e3520000 1592a000 e3a01000 
04-27 10:42:13.328: I/DEBUG(8926): 8001d0a4 0affff8a e1f970b6 e5862010 e59a1028 
04-27 10:42:13.328: I/DEBUG(8926): stack: 
04-27 10:42:13.328: I/DEBUG(8926):  4472fb48 4472fbe0 
04-27 10:42:13.328: I/DEBUG(8926):  4472fb4c 4214cce4 
04-27 10:42:13.328: I/DEBUG(8926):  4472fb50 0000ce60 
04-27 10:42:13.328: I/DEBUG(8926):  4472fb54 00000001 
04-27 10:42:13.328: I/DEBUG(8926):  4472fb58 4472fbe0 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb5c 80049697 /system/lib/libdvm.so 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb60 4214cce4 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb64 431fbec9 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb68 ad34675d /system/lib/libandroid_runtime.so 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb6c 4472fbe0 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb70 42f8e91e 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb74 4214cd00 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb78 4472fbd8 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb7c 40038360 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb80 df002777 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb84 e3a070ad 
04-27 10:42:13.338: I/DEBUG(8926): #00 4472fb88 4214e32c 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb8c 4472fbd8 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb90 00000001 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb94 002c2c40 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb98 0000ce68 
04-27 10:42:13.338: I/DEBUG(8926):  4472fb9c 000f45b8 
04-27 10:42:13.338: I/DEBUG(8926):  4472fba0 800aad38 
04-27 10:42:13.338: I/DEBUG(8926):  4472fba4 fffffe84 
04-27 10:42:13.338: I/DEBUG(8926):  4472fba8 800a5368 
04-27 10:42:13.338: I/DEBUG(8926):  4472fbac 800220e8 /system/lib/libdvm.so 
04-27 10:42:13.338: I/DEBUG(8926): #01 4472fbb0 4472fbd8 
04-27 10:42:13.338: I/DEBUG(8926):  4472fbb4 0000ce60 
04-27 10:42:13.338: I/DEBUG(8926):  4472fbb8 80022058 /system/lib/libdvm.so 
04-27 10:42:13.338: I/DEBUG(8926):  4472fbbc 423298c8 
04-27 10:42:13.338: I/DEBUG(8926):  4472fbc0 00000000 
04-27 10:42:13.338: I/DEBUG(8926):  4472fbc4 80020fe0 /system/lib/libdvm.so

任何想法是表示讚賞。

謝謝。

該項目的本機端：在thread_function獲取的所謂的週期性（2秒間隔）而這也正是我打電話Java代碼中定義的函數。

// Callbacks to Android 
JavaVM *j_vm; 
jobject *j_obj; 
JNIEnv *j_env; 
jclass j_cls; 
jmethodID android_call; 

int JNI_OnLoad(JavaVM* vm, void* reserved) { 
    j_vm = vm; 
    (*j_vm)->GetEnv(j_vm, (void**) &j_env, JNI_VERSION_1_6); 
    j_cls = (*j_env)->FindClass(j_env, "<package_name>/<class_name>"); 
    android_call = (*j_env)->GetMethodID(j_env, j_cls, "callFromNDK", "()V"); 
    j_obj = (*j_env)->NewGlobalRef(j_env, (*j_env)->NewObject(j_env, j_cls, android_call)); 
    return JNI_VERSION_1_6; 
} 

void JNI_OnUnload(JavaVM *vm, void *reserved) { 
    (*j_env)->DeleteGlobalRef(j_env, j_obj); 
} 

void *thread_function(void *ptr) { 
    int *which = (int *) ptr; 
    (*j_vm)->AttachCurrentThread(j_vm, &j_env, NULL); 
    int rc; 
    while (!stop_thread) { 
     rc = pthread_mutex_lock(&mtx); 
     rc = pthread_cond_wait(&cond, &mtx); 
     rc = pthread_mutex_unlock(&mtx); 
     if (!stop_thread) { 
      (*j_env)->CallVoidMethod(j_env, j_obj, android_call); 
     } 
    } 
    (*j_vm)->DetachCurrentThread(j_vm); 
    return NULL; 
}

來源

2012-04-27 VJ Vélan Solutions

什麼是調用thread_function？不管它的具體問題，我想你可以添加周圍的mediaPlayer.start（）的一些記錄和異常處理 - 也已經在這一點上編制的，對不對？值得重新閱讀的mediaplyer文檔。 – 2012-04-27 18:33:35

thread_function是在創建線程時註冊的函數指針。這是線程開始運行時調用的函數。是的，mediaPlayer實例被創建並且非空。該應用程序運行約15或20分鐘，然後崩潰。應用程序崩潰花費的時間長度不確定。對mediaPlayer.start（）進行調試日誌並沒有幫助，因爲這不是問題所在。正如@StarDust指出的那樣，問題必須出現在我的本地代碼中。你可以給我一些關於如何調試本地代碼而不是放置日誌語句的指導嗎？謝謝。 – 2012-04-27 23:55:36

問題可能是在你的代碼，但轉儲表明實際崩潰發生在libdvm.so代替。因此，您需要弄清楚您的代碼可能會將DVM設置爲崩潰。在崩潰之前執行的代碼最後一行記錄事件狀態可能會有所幫助，特別是在對mediaPlayer對象錯誤使用的情況下。爲了更好地識別代碼中的最後一點，可以使用地址來指定工具或objdump來識別堆棧轉儲中提到的libtest-jni.so中的兩個點。你也可以設置GDB ... – 2012-04-28 00:02:47

您是否試過在模擬器中運行它？由於它在libdvm中崩潰，您可能會在本機崩潰之前獲得一些非常有用的日誌記錄。

的問題可能是以下行：

j_cls = (*j_env)->FindClass(j_env, "<package_name>/<class_name>");

它是安全的假設你的實際命名空間和類名替換"<package_name>/<class_name>"？

來源

2012-04-28 21:08:59 Bellinghammer

是的。假設package_name和class_name的詳細信息是正確的並且它們完全合格，這是安全的。我沒有嘗試模擬器，因爲程序需要音頻輸入才能工作。但這是一個很好的建議。我會嘗試隔離音頻輸入部分，並使用模擬器，看看會發生什麼。謝謝。 – 2012-05-01 01:52:49

由於我在這段代碼中看到了三個錯誤，但是運行CheckJNI（http://android-developers.blogspot.com/2011/07/debugging-android-jni-with-checkjni.html）和Dalvik應該告訴你你做錯了什麼。（你應該運行最新的版本以獲得最佳檢查結果，我注意到的一個錯誤不會被薑餅發現[並且你也會在薑餅中得到它）。）

你應該總是使用CheckJNI，同時開發和調試。在發佈任何包含單詞JNI的問題之前，StackOverflow應該可能讓人們檢查「是的，我試過CheckJNI」框：

來源

2012-04-30 13:58:27

不知道CheckJNI - 新手JNI用戶在這裏。我會通過CheckJNI查看是否所有代碼都正確。 thx爲小費。 – 2012-05-01 01:54:03

JNI - 應用程序崩潰

回答

相關問題