1

AttachCurrentThread method crashes with this error, I use:

static JavaVM *g_jvm;

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved) {
    g_jvm = vm;
    JNIEnv *env;
    return JNI_VERSION_1_4;
}

void treadmileCallback(SearchResult result) {
    JNIEnv *env;
    jint i = (*g_jvm)->GetEnv(g_jvm, &env, JNI_VERSION_1_4);
    if( i == JNI_EDETACHED) {
    }

    (*g_jvm)->AttachCurrentThread(g_jvm, &env, NULL);
    .....
}

A/art: art/runtime/thread.cc:2950] **Unable to create protected region
 in stack for implicit overflow check.
 Reason: Invalid argument size:  4096**

A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb8 in tid 5645 (ngiot.sdk.xqiao)
[ 04-25 02:49:22.472  1058: 1058 W/]debuggerd: handling request: pid=5627 uid=10251 gid=10251 tid=5645

Android Studio:3.0.1
Android version:7.1.1

Thanks very much, I don't know how to solve this problem, nothing.

Jon Goodwin
  • 9,053
  • 5
  • 35
  • 54
beautifulcode
  • 364
  • 3
  • 6
  • 1
    Why is the `AttachCurrentThread` call done unconditionally? At least that's the way it looks from the code you've posted. Side note: every Android version released in the last 7-8 years (or more) has supported `JNI_VERSION_1_6`. – Michael Apr 24 '18 at 20:15
  • JNI_VERSION _1_ 4 is not the key point.When I call AttachCurrentThread method, it directly report error and is "A/art: art/runtime/thread. The cc: 2950] ... ", like soso "Invalid argument size:4096" – beautifulcode Apr 25 '18 at 01:46
  • Right, but why are you calling `AttachCurrentThread` unconditionally, regardless of what `GetEnv` returned? That can screw things up when you try to detach the thread later on. See [this answer](https://stackoverflow.com/questions/30026030/what-is-the-best-way-to-save-jnienv/30026231#30026231) for an example of how to get a `JNIEnv*` from any thread. – Michael Apr 25 '18 at 06:05
  • @Michael it's OK to call `AttachCurrentThread()` this way, this is a noop for thread that is already attached (see [this discussion circa 2010](https://groups.google.com/d/msg/android-ndk/5zfGd6yr_2E/pUTWxi9UMqwJ)). – Alex Cohn Apr 25 '18 at 07:37
  • @AlexCohn: Exactly. _Attach_ is a noop if the thread is already attached, but _Detach_ is not a noop under any cicumstance last time I checked. So you'll want to know whether you explictly attached the thread to the VM when the time comes to determine if you should call `DetachCurrentThread`. The alternative of never detaching the thread doesn't seem like a good idea, since `AttachCurrentThread` most likely leads to some memory being allocated. – Michael Apr 25 '18 at 09:19
  • The common practice is to `AttachCurrentThread` without doubt, and set a **pthread_key_create** destructor function to have `DetachCurrentThread` happen automatically. RAII is not the best pattern here, because every 'first' attach is quite expensive. Fadden explained that the overhead of keeping a thread attached is negligible. – Alex Cohn Apr 25 '18 at 10:59
  • How do you create the thread 5645? Could it be a thread that comes from Java? – Alex Cohn Apr 25 '18 at 11:23

0 Answers0