Android: Crash/abort in djinni::jniGetThreadEnv()

[TechN8]

It looks like m_ui_thread thread is not attached to the JNI environment at (djinni_support.cpp:48)/.

const jint get_res = g_cachedJVM->GetEnv(reinterpret_cast<void**>(&env), JNI_VERSION_1_6);

returns -2 (JNI_EDETACHED)

\ Crash dump: ** Build fingerprint: 'google/occam/mako:4.3/JWR66Y/776638:user/release-keys' pid: 19194, tid: 19207, name: com.mx3 >>> com.mx3 <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad Stack frame #00 pc 0001e348 /system/lib/libc.so Stack frame #01 pc 0001c510 /system/lib/libc.so (abort+4) Stack frame #02 pc 00013e87 /data/app-lib/com.mx3-1/libmx3_android.so: Routine djinni::jniGetThreadEnv() at mx3/example_android/app/../../deps/djinni/support-lib/jni/djinni_support.cpp:48 Stack frame #03 pc 00012d57 /data/app-lib/com.mx3-1/libmx3_android.so: Routine djinni_generated::NativeEventLoop::JavaProxy::post(std::shared_ptr const&) at mx3/example_android/app/../../android/jni_gen/native_event_loop.cpp:14

[skabbes]

Hmm, do you have any more info on this? How often does this happen, what kind of device, which android version etc.

[TechN8]

It happens every time. Android 4.3 on LG Google Nexus 4. I was able to work around this error by calling AttachCurrentThread from djinni_support.cpp. There should probably be a corresponding call to DetachCurrentThread somewhere, but I wasn't sure where to put it. You can see my work-around on my fork of djinni: https://github.com/TechN8/djinni/commit/96a9ab165864f909e6fcc1e382d82847a664949c

[skabbes]

Thanks for the bug report, I'm looking into the root of this - seems like just attaching will be the right fix though.

[skabbes]

So, @TechN8 just to follow up on this. I think that there are deeper issues with thread creation in a JNI context. Read this. Simply attaching the thread fixes some issues, but not all of them.

I think with that in mind, the work around isn't 100% ideal - in some cases you'll still need a proper class loader. That said, the docs seem to read that it will be deterministic - so that's good.

The best solution I know so far is to call into java to create your thread, or load all your classes up front (as suggested by the JNI tips page).

[skabbes]

Hey @TechN8 I believe that launching threads from Java should fix this issue for you completely. No more classloader issues.

[TechN8]

Yes, if I use the thread created from Java, it works. Do you plan to update the android MX3 example to do this?