What causes " error: (no exception)" in apache/hadoop?

Treat this as a JVM-level failure: check LIBHDFS_OPTS -Xmx and the process's memory footprint (RSS vs cgroup/rlimit).

error: (no exception)

Error message

 error: (no exception)

What it means

printPendingExceptionAndFree first calls ExceptionOccurred(); if no Java exception is actually pending it prints this fragment and returns 0. It signals that a libhdfs error path was entered without a thrown exception - typically a JNI function returned NULL/error without raising one, which is classic JVM resource-exhaustion behavior - so there is nothing to describe or map to an errno.

Source

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

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

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

    exc = (*env)->ExceptionOccurred(env);
    if (!exc) {
        va_start(ap, fmt);
        vfprintf(stderr, fmt, ap);
        va_end(ap);
        fprintf(stderr, " error: (no exception)");
        ret = 0;
    } else {
        (*env)->ExceptionClear(env);
        va_start(ap, fmt);
        ret = printExceptionAndFreeV(env, exc, noPrintFlags, fmt, ap);
        va_end(ap);
    }
    return ret;
}

jthrowable getPendingExceptionAndClear(JNIEnv *env)
{
    jthrowable jthr = (*env)->ExceptionOccurred(env);
    if (!jthr)
        return NULL;
    (*env)->ExceptionClear(env);
    return jthr;
}

View on GitHub (pinned to 2add963021)

Solutions

Treat this as a JVM-level failure: check LIBHDFS_OPTS -Xmx and the process's memory footprint (RSS vs cgroup/rlimit).
Audit the code path: if a JNI call can fail without throwing, set a meaningful errno before the print helper is called instead of relying on it.
Reproduce with `hdfs dfs` under the same CLASSPATH to see whether the Java side fails identically.
Upgrade to a matched libhdfs + Hadoop jar set if the pattern persists across releases.

Defensive patterns

Strategy: validation

Validate before calling

// validate JNI-level results instead of trusting errno after libhdfs calls
hdfsFile f = hdfsOpenFile(fs, path, O_WRONLY | O_CREAT, 0, 0, 0);
if (!f && errno == 0) {
    /* '(no exception)' path: JNI failed without a Java exception - JVM-level trouble */
    treat_as_jvm_resource_failure();
}

Try / catch

hdfsFile f = hdfsOpenFile(fs, path, O_WRONLY, 0, 0, 0);
if (!f) {
    if (errno == 0 || errno == EINTERNAL) {
        /* no pending exception was found: JVM-side failure, check heap/JVM state */
    } else {
        /* normal mapped-exception path */
    }
}

Prevention

Never assume errno is set when a libhdfs handle comes back NULL - check it explicitly.
Monitor and cap JVM memory (LIBHDFS_OPTS -Xmx) in processes embedding libhdfs; JNI calls failing without exceptions are a classic exhaustion signature.
Keep libhdfs and Hadoop jars version-matched.
In wrappers around libhdfs, set a synthetic errno (e.g. EIO) when errno==0 after a failed call.

When it happens

Trigger: Example: the hdfsOpenFile NewGlobalRef failure path - NewGlobalRef returns NULL without throwing, printPendingExceptionAndFree is called, ExceptionOccurred() is NULL, so this prints and ret stays 0 while the operation still failed (NULL handle).

Common situations: JVM heap/native exhaustion inside long-running libhdfs clients; error-handling paths invoked after an exception was already cleared elsewhere; rarely, JNI bugs across JVM versions.

Related errors

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