Собственный сбой: JNI ОБНАРУЖИЛА ОШИБКУ В ПРИЛОЖЕНИИ: [поток], используя JNIEnv * из [поток] - PullRequest
0 голосов
/ 29 июня 2018

Ниже приведена трассировка стека. Исходный код, из-за которого происходит сбой: здесь .

Я проследил трассировку стека до исходного кода Android, который здесь .

Я не могу понять, что это значит и почему это происходит только иногда. Любая помощь будет оценена. Рады поделиться более подробной информацией.

Мы смогли воспроизвести этот сбой на устройстве Android 7.0. Но это не соответствует.

06-28 19:09:26.147  5696  5696 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-28 19:09:26.147  5696  5696 F DEBUG   : Native Crash TIME: 265472
06-28 19:09:26.147  5696  5696 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-28 19:09:26.148  5696  5696 F DEBUG   : Build fingerprint: 'Karbonn/K9_Smart_Eco/K9_Smart_Eco:7.0/NRD90M/1498048597:user/release-keys'
06-28 19:09:26.148  5696  5696 F DEBUG   : Revision: '0'
06-28 19:09:26.148  5696  5696 F DEBUG   : ABI: 'arm'
06-28 19:09:26.148  5696  5696 F DEBUG   : pid: 5587, tid: 5689, name: JS Thread  >>> com.hashcube.sqmtest <<<
06-28 19:09:26.149  5696  5696 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
06-28 19:09:26.152  5696  5696 F DEBUG   : Abort message: 'art/runtime/java_vm_ext.cc:470] JNI DETECTED ERROR IN APPLICATION: thread Thread[54,tid=5689,Native,Thread*=0x8a4de500,peer=0x12dc89d0,"JS Thread"] using JNIEnv* from thread Thread[54,tid=5689,Native,Thread*=0x8a4de500,peer=0x12dc89d0,"JS Thread"]'
06-28 19:09:26.152  5696  5696 F DEBUG   :     r0 00000000  r1 00001639  r2 00000006  r3 00000008
06-28 19:09:26.152  5696  5696 F DEBUG   :     r4 899ff978  r5 00000006  r6 899ff920  r7 0000010c
06-28 19:09:26.152  5696  5696 F DEBUG   :     r8 00000000  r9 add696a4  sl 00000ac4  fp add2eecf
06-28 19:09:26.153  5696  5696 F DEBUG   :     ip 0000000b  sp 899feb50  lr b039a597  pc b039cdf4  cpsr 20070010
06-28 19:09:26.192  5696  5696 F DEBUG   :
06-28 19:09:26.192  5696  5696 F DEBUG   : backtrace:
06-28 19:09:26.193  5696  5696 F DEBUG   :     #00 pc 00049df4  /system/lib/libc.so (tgkill+12)
06-28 19:09:26.193  5696  5696 F DEBUG   :     #01 pc 00047593  /system/lib/libc.so (pthread_kill+34)
06-28 19:09:26.193  5696  5696 F DEBUG   :     #02 pc 0001d855  /system/lib/libc.so (raise+10)
06-28 19:09:26.193  5696  5696 F DEBUG   :     #03 pc 000193a1  /system/lib/libc.so (__libc_android_abort+34)
06-28 19:09:26.193  5696  5696 F DEBUG   :     #04 pc 00017014  /system/lib/libc.so (abort+4)
06-28 19:09:26.193  5696  5696 F DEBUG   :     #05 pc 003188f5  /system/lib/libart.so (_ZN3art7Runtime5AbortEv+252)
06-28 19:09:26.194  5696  5696 F DEBUG   :     #06 pc 000b4e79  /system/lib/libart.so (_ZN3art10LogMessageD2Ev+864)
06-28 19:09:26.194  5696  5696 F DEBUG   :     #07 pc 00238971  /system/lib/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+1664)
06-28 19:09:26.194  5696  5696 F DEBUG   :     #08 pc 00238b63  /system/lib/libart.so (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+58)
06-28 19:09:26.194  5696  5696 F DEBUG   :     #09 pc 000ca81b  /system/lib/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz+46)
06-28 19:09:26.194  5696  5696 F DEBUG   :     #10 pc 000ca305  /system/lib/libart.so (_ZN3art11ScopedCheck11CheckThreadEP7_JNIEnv+104)
06-28 19:09:26.194  5696  5696 F DEBUG   :     #11 pc 000c941f  /system/lib/libart.so (_ZN3art11ScopedCheck22CheckPossibleHeapValueERNS_18ScopedObjectAccessEcNS_12JniValueTypeE+26)
06-28 19:09:26.195  5696  5696 F DEBUG   :     #12 pc 000c88fb  /system/lib/libart.so (_ZN3art11ScopedCheck5CheckERNS_18ScopedObjectAccessEbPKcPNS_12JniValueTypeE+802)
06-28 19:09:26.195  5696  5696 F DEBUG   :     #13 pc 000cdd79  /system/lib/libart.so (_ZN3art8CheckJNI8GetFieldEPKcP7_JNIEnvP8_jobjectP9_jfieldIDbNS_9Primitive4TypeE+496)
06-28 19:09:26.195  5696  5696 F DEBUG   :     #14 pc 000c2eef  /system/lib/libart.so (_ZN3art8CheckJNI11GetIntFieldEP7_JNIEnvP8_jobjectP9_jfieldID+42)
06-28 19:09:26.195  5696  5696 F DEBUG   :     #15 pc 0009a35c  /data/app/com.hashcube.sqmtest-1/lib/arm/libtealeaf.so (_Z19navigator_info_initv+252)
06-28 19:09:26.195  5696  5696 F DEBUG   :     #16 pc 00084ca0  /data/app/com.hashcube.sqmtest-1/lib/arm/libtealeaf.so (_Z25js_navigator_get_templatev+100)
06-28 19:09:26.196  5696  5696 F DEBUG   :     #17 pc 0007caf0  /data/app/com.hashcube.sqmtest-1/lib/arm/libtealeaf.so (init_js+740)
06-28 19:09:26.196  5696  5696 F DEBUG   :     #18 pc 00089dc4  /data/app/com.hashcube.sqmtest-1/lib/arm/libtealeaf.so (core_init_js+36)
06-28 19:09:26.196  5696  5696 F DEBUG   :     #19 pc 00099a28  /data/app/com.hashcube.sqmtest-1/lib/arm/libtealeaf.so (Java_com_tealeaf_NativeShim_initJS+180)
06-28 19:09:26.196  5696  5696 F DEBUG   :     #20 pc 0088494d  /data/app/com.hashcube.sqmtest-1/oat/arm/base.odex (offset 0x82e000)

1 Ответ

0 голосов
/ 06 июля 2018

Похоже, что ваша функция вызывается из собственного потока, и это приводит к сбоям вызова FindClass и других методов JNI, которые пытаются работать с кодом Java

06-28 19: 09: 26,194 5696 5696 F ОТЛАДКА: # 09 pc 000ca81b /system/lib/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz + 46)

06-28 19: 09: 26,194 5696 5696 F DEBUG: # 10 pc 000ca305 /system/lib/libart.so (_ZN3art11ScopedCheck11CheckThreadEP7_JNIEnv + 104)

В вашем коде в файле jni / platform / native_shim.cpp я вижу:

static JNIEnv* get_env() {
    JNIEnv* env;
    static_vm->AttachCurrentThread(&env, NULL);
    return env;
}

native_shim *get_native_shim() {
    if(shim.instance == NULL) {
        LOG("{native} ERROR: Tried to get native shim when there wasn't one");
#if DEBUG
        *((int*)0) = -1;
#else
        exit(1);
#endif
    }
    shim.env = get_env();
    return &shim;
}

В строке static_vm->AttachCurrentThread(&env, NULL); вы пытаетесь присоединить текущий поток к JVM с нулевым указателем JNIEnv. Вы объявили это, но никогда не назначали. Я искал функцию JNI_OnLoad в ваших файлах, но не нашел ее. Рекомендуется один раз получить JavaVM в этом методе и сохранить его где-нибудь, чтобы вы могли получить указатель JNIEnv из него там, где вам нужно. Это может быть функция, подобная следующей:

JavaVM *java_machine;
jint JNI_OnLoad(JavaVM *vm, void *reserved) {
   java_machine = vm;
}
int get_env(JNIEnv **g_env) {
    int getEnvStat = java_machine->GetEnv((void **) g_env, JNI_VERSION_1_6);
    if (getEnvStat == JNI_EDETACHED) {
        if (java_machine->AttachCurrentThread(g_env, nullptr) != 0) {
            __android_log_print(ANDROID_LOG_ERROR, "GetEnvironmentRoutine", "FAILED ATTACH THREAD");
            return 2; //Failed to attach
        }
        return 1; //Attached. Need detach
    }
    return 0;//Already attached
}

И вы должны вызвать java_machine->DetachCurrentThread(); в конце метода, потому что, если присоединенный собственный поток завершает работу без отсоединения, это вызовет сбой java-машины.

Вы также можете написать оболочку RAII, чтобы быть уверенным, что ваш поток отсоединен от всех ветвей метода.

class attached_env final {
public:
    attached_env() {
        auto resCode = get_env(&mEnv);
        if (resCode == 2)
            throw std::runtime_error("Cannot retrieve JNI environment");
        needDetach = (resCode == 1);
    }

    ~attached_env() {
        if (needDetach) {
            java_machine->DetachCurrentThread();
        }
    }

    JNIEnv *env() const noexcept {
        return mEnv;
    }

private:
    JNIEnv *mEnv;
    bool needDetach;
};

template<typename Callable>
auto call_in_attached_thread(Callable func) {
    attached_env env;
    return func(env.env());
}

Таким образом, ваш метод может выглядеть следующим образом (необходимо уточнить, см. Ниже):

navigator_info* navigator_info_init() {
    call_in_attached_thread([=](auto env) {    
       jclass display_metrics_class = (jclass)env->FindClass("android/util/DisplayMetrics");//WILL NOT WORK! SEE BELOW
       jfieldID density_dpi = env->GetFieldID(display_metrics_class, "densityDpi", "I");
       jfieldID xdpi = env->GetFieldID(display_metrics_class, "xdpi", "F");    
       //And so on...
       ...
    });

Следующее, что необходимо принять во внимание, это то, что вы не можете использовать функцию FindClass для поиска пользовательских классов, если в вашем Java-коде не запущен стек вызовов. Таким образом, в собственных потоках (независимо от того, присоединены они или нет) вызов FindClass в большинстве случаев приведет к сбою. Вам нужно найти классы в JNI_OnLoad и сохранить их в глобальных переменных, используя глобальные ссылки на Java:

jclass globalDisplayMetricsClassRef;

jint JNI_OnLoad(JavaVM *vm, void *reserved) {
    //
    //previous code here
    //
    auto localRef = env->FindClass("android/util/DisplayMetrics");
    globalDisplayMetricsClassRef = (jclass)env->NewGlobalRef(localRef);
}

Итак, наконец мы получаем:

navigator_info* navigator_info_init() {
    call_in_attached_thread([=](auto env) {    
       jfieldID density_dpi = env->GetFieldID(globalDisplayMetricsClassRef, "densityDpi", "I");
       jfieldID xdpi = env->GetFieldID(display_metrics_class, "xdpi", "F");    
       //And so on...
       ...
    });

ОБНОВЛЕНИЕ:

Кусок кода из функции ART CheckThread

   // Verify that the current thread is (a) attached and (b) associated with
    // this particular instance of JNIEnv.
    if (soa_.Env() != threadEnv) {
      if (soa_.Vm()->work_around_app_jni_bugs) {
        // If we're keeping broken code limping along, we need to suppress the abort...
        LOG(ERROR) << "APP BUG DETECTED: thread " << *self << " using JNIEnv* from thread " << *soa_.Self();
      } else {
        JniAbortF(function_name_, "thread %s using JNIEnv* from thread %s",
                  ToStr<Thread>(*self).c_str(), ToStr<Thread>(*soa_.Self()).c_str());
        return;
      }
    }
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...