What causes "(unable to get stack trace for %s) " in apache/hadoop?

Verify a single consistent Hadoop version on CLASSPATH (hdfs classpath --glob from the matching install).

(unable to get stack trace for %s)

Error message

(unable to get stack trace for %s)

What it means

printExceptionAndFreeV calls org.apache.hadoop.util.ExceptionUtils.getStackTrace over JNI to render the Java stack trace of a failed libhdfs operation; when getExceptionUtilString returns NULL (invokeMethod threw or the C-string copy failed), this placeholder with the exception class name is printed instead. The errno mapping and root-cause extraction are independent, so they may still succeed.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfs/exception.c:195

    // We don't want to use ExceptionDescribe here, because that requires a
    // pending exception. Instead, use ExceptionUtils.
    rootCause = getExceptionUtilString(env, exc, "getRootCauseMessage");
    stackTrace = getExceptionUtilString(env, exc, "getStackTrace");
    // Save the exception details in the thread-local state.
    setTLSExceptionStrings(rootCause, stackTrace);

    if (!noPrint) {
        vfprintf(stderr, fmt, ap);
        fprintf(stderr, " error:\n");

        if (!rootCause) {
            fprintf(stderr, "(unable to get root cause for %s)\n", className);
        } else {
            fprintf(stderr, "%s", rootCause);
        }
        if (!stackTrace) {
            fprintf(stderr, "(unable to get stack trace for %s)\n", className);
        } else {
            fprintf(stderr, "%s", stackTrace);
        }
    }

    destroyLocalReference(env, exc);
    free(className);
    return excErrno;
}

int printExceptionAndFree(JNIEnv *env, jthrowable exc, int noPrintFlags,
        const char *fmt, ...)
{
    va_list ap;
    int ret;

    va_start(ap, fmt);
    ret = printExceptionAndFreeV(env, exc, noPrintFlags, fmt, ap);

View on GitHub (pinned to 2add963021)

Solutions

Verify a single consistent Hadoop version on CLASSPATH (hdfs classpath --glob from the matching install).
Use hdfsGetLastExceptionRootCause() - the root cause is fetched by a separate call and may still be available.
Reproduce the failing operation with `hdfs dfs` using the same CLASSPATH to capture the stack trace from the Java side.
Raise LIBHDFS_OPTS -Xmx if both root-cause and stack-trace diagnostics fail (points at JVM OOM).

Defensive patterns

Strategy: fallback

Try / catch

const char *st = hdfsGetLastExceptionStackTrace();
if (!st) {
    /* stack trace unavailable: fall back to root cause + mapped errno */
    const char *rc = hdfsGetLastExceptionRootCause();
    handle_failure(errno, rc ? rc : "no diagnostics available");
} else {
    handle_failure(errno, st);
}

Prevention

Keep hadoop-common and libhdfs versions identical so ExceptionUtils.getStackTrace resolves.
Reproduce failures with `hdfs dfs` under the same CLASSPATH to capture the Java-side trace when native diagnostics fail.
Treat 'both root cause and stack trace NULL' as a JVM-memory red flag.
Always handle NULL from hdfsGetLastExceptionStackTrace().

When it happens

Trigger: A libhdfs operation threw a Java exception AND the ExceptionUtils.getStackTrace call failed: hadoop-common on CLASSPATH too old to have that method (pre-3.x jar), JVM OOM while formatting, or newCStr allocation failure.

Common situations: Mixed-version hadoop jars on CLASSPATH; memory-pressured JVMs where diagnostic calls fail after the main operation already threw; stripped-down hadoop-common bundles.

Related errors

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