oracle/graal · error · IllegalArgumentException

Can not request %d bytes: buffer capacity is %d

Error message

Can not request %d bytes: buffer capacity is %d

What it means

BinarySource decodes through a fixed 256 KB direct ByteBuffer; ensureAvailable rejects any single read whose required byte count exceeds that capacity with IllegalArgumentException('Can not request N bytes: buffer capacity is M'). In practice N comes from a length prefix in the file (e.g. a string or byte-array length), so a huge value almost always means the stream is corrupt or misaligned rather than that a legitimate 256 KB+ item exists.

Source

Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/graphio/parsing/BinarySource.java:286

            return null;
        }
        ensureAvailable(len * 4);
        int[] props = new int[len];
        for (int i = 0; i < len; i++) {
            props[i] = buffer.getInt();
        }
        return props;
    }

    @Override
    public String readString() throws IOException {
        // readString is only called from CP reads, CP items are cached, no need to intern
        return new String(readBytes(), StandardCharsets.UTF_8);
    }

    private void ensureAvailable(int i) throws IOException {
        if (i > buffer.capacity()) {
            throw new IllegalArgumentException(String.format("Can not request %d bytes: buffer capacity is %d", i, buffer.capacity()));
        }
        while (buffer.remaining() < i) {
            fill();
        }
    }

    @Override
    public boolean readHeader() throws IOException {
        // Check for a version specification
        byte[] magic = peekBytes(MAGIC_BYTES.length);
        if (Arrays.equals(MAGIC_BYTES, magic)) {
            // Consume the bytes for real
            readBytes(MAGIC_BYTES.length);
            setVersion(readByte(), readByte());
            return true;
        } else {
            return false;
        }

View on GitHub (pinned to a66e9ccd1d)

Solutions

1. Regenerate the dump; treat this as corruption evidence and verify file integrity first.
2. If you control the writer, split oversized entries (strings/byte arrays) or confirm they stay under 256 KB.
3. If large entries are legitimate for your format, read via a source with a larger buffer or a streaming read path rather than relying on the fixed-capacity buffer.
4. Check the requested byte count in the message: values near Integer.MAX_VALUE strongly indicate misalignment, not real data.

try { reader.parse(); } catch (IllegalArgumentException e) { if (e.getMessage().contains("buffer capacity")) { /* corrupt length field or oversized entry: verify/re-dump */ } }

When it happens

Trigger: A corrupted length field (e.g. reading random bytes as an int length) producing a request > 262144; stream desynchronization causing a data value to be interpreted as a length; genuinely oversized pool entries written by custom producers.

Common situations: Parsing damaged/truncated dumps; reading files whose earlier fields were misparsed, shifting bytes; custom writers emitting very large code blobs or strings in single pool entries.

Related errors

• Invalid constant pool index :
• unknown klass type :
• unknown pool type
• Unknown type
• File header is missing

AI-assisted analysis of oracle/graal@a66e9ccd1d (2026-08-14). Data as JSON: /api/errors/84664f42471ddc92. Report an issue: GitHub.