hdfsThreadDestructor: Unable to detach thread %s from the JV

Error message

hdfsThreadDestructor: Unable to detach thread %s from the JVM. Error code: %d

What it means

The POSIX TLS destructor called DetachCurrentThread and the JVM returned something other than JNI_OK — commonly JNI_EDETACHED when the thread was not (or no longer) attached. The printed thread name comes from get_current_thread_id via the JVM. The destructor still frees the state afterwards, so this is a teardown-time warning rather than a crash.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfs/os/posix/thread_local_storage.c:78

      fprintf(stderr, "hdfsThreadDestructor: GetJavaVM failed with error %d\n",
        ret);
      jthr = (*env)->ExceptionOccurred(env);
      if (jthr) {
        (*env)->ExceptionDescribe(env);
        (*env)->ExceptionClear(env);
      }
    } else {
      ret = (*vm)->DetachCurrentThread(vm);

      if (ret != JNI_OK) {
        jthr = (*env)->ExceptionOccurred(env);
        if (jthr) {
          (*env)->ExceptionDescribe(env);
          (*env)->ExceptionClear(env);
        }
        get_current_thread_id(env, thr_name, MAXTHRID);

        fprintf(stderr, "hdfsThreadDestructor: Unable to detach thread %s "
            "from the JVM. Error code: %d\n", thr_name, ret);
      }
    }
  }

  /* Free exception strings */
  if (state->lastExceptionStackTrace) free(state->lastExceptionStackTrace);
  if (state->lastExceptionRootCause) free(state->lastExceptionRootCause);

  /* Free the state itself */
  free(state);
}

static void get_current_thread_id(JNIEnv* env, char* id, int max) {
  jvalue jVal;
  jobject thr = NULL;
  jstring thr_name = NULL;
  jlong thr_id = 0;

View on GitHub (pinned to 2add963021)

Solutions

Treat as informational when it appears during process shutdown
If reproducible mid-run, audit other JNI libraries in-process for double detach
Make threads finish all HDFS work before hdfsDisconnect and teardown paths begin

Defensive patterns

Strategy: fallback

Prevention

Avoid multiple native libraries double-detaching the same thread from the JVM
Complete HDFS operations before initiating JVM teardown
Treat mid-run occurrences as a signal of conflicting JNI management; shutdown-only occurrences as noise

When it happens

Trigger: Thread exit after another component already detached it from the JVM; detach attempted while DestroyJavaVM is tearing the runtime down and the JVM refuses.

Common situations: Multiple native libraries managing attachment in one process; shutdown ordering races between thread exits and JVM destruction.

Related errors

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/f139cde1bfa13c6b. Report an issue: GitHub.