openjdk/jdk · critical

-javaagent: memory allocation failed\n

Error message

-javaagent: memory allocation failed\n

What it means

After validating the Premain-Class name, the launcher duplicates or re-encodes it (strdup, or malloc+convertUtf8ToModifiedUtf8 for names containing non-ASCII) and the allocation returned NULL. Startup aborts with JNI_ERR. Like error 133 this is an early-startup native OOM, just at a later step — the message has no trailing period, distinguishing it from the parse-time one.

Source

Thrown at src/java.instrument/share/native/libinstrument/InvocationAdapter.c:225

         */
        if (oldLen < 0 || newLen < 0 || newLen > 0xFFFF) {
            fprintf(stderr, "-javaagent: Premain-Class value is too big\n");
            free(jarfile);
            if (options != NULL) free(options);
            freeAttributes(attributes);
            return JNI_ERR;
        }
        if (newLen == oldLen) {
            premainClass = strdup(premainClass);
        } else {
            char* str = (char*)malloc( newLen+1 );
            if (str != NULL) {
                convertUtf8ToModifiedUtf8(premainClass, oldLen, str, newLen);
            }
            premainClass = str;
        }
        if (premainClass == NULL) {
            fprintf(stderr, "-javaagent: memory allocation failed\n");
            free(jarfile);
            if (options != NULL) free(options);
            freeAttributes(attributes);
            return JNI_ERR;
        }

        /*
         * If the Boot-Class-Path attribute is specified then we process
         * each relative URL and add it to the bootclasspath.
         */
        bootClassPath = getAttribute(attributes, "Boot-Class-Path");
        if (bootClassPath != NULL) {
            appendBootClassPath(agent, jarfile, bootClassPath);
        }

        /*
         * Convert JAR attributes into agent capabilities
         */

View on GitHub (pinned to 88dfb74bbe)

Solutions

  1. Relieve memory pressure before launch: stop other processes or raise the container/host memory
  2. Use a 64-bit JVM or reduce -Xmx to leave native allocation room
  3. Retry the launch after freeing resources — transient pressure at init is the usual cause
  4. If persistent, capture native memory usage to rule out a launcher-level leak in custom launchers
Defensive patterns

Strategy: retry

Validate before calling

// script-level: only attempt launch when memory is available
// free -m | awk '/Mem:/{exit ($4 < 256) ? 1 : 0}' || { echo 'wait for memory'; exit 1; }

Prevention

When it happens

Trigger: Same launch path (DEF_Agent_OnLoad) as 133-136, reached with a valid jar/manifest, but malloc(newLen+1) or strdup fails — 32-bit address space exhausted, container memory limit, or extreme memory pressure during JVM init. Very rare in normal operation.

Common situations: 32-bit JVM with oversized -Xmx; cgroup memory ceiling; swap disabled under pressure; the same conditions that produce error 133 but striking a few allocations later.

Related errors


AI-assisted analysis of openjdk/jdk@88dfb74bbe (2026-08-14). Data as JSON: /api/errors/3e64980cb87b7ecf. Report an issue: GitHub.