eclipse-vertx/vert.x · error · IndexOutOfBoundsException

<index> + <size> > <length>

Error message

<index> + <size> > <length>

What it means

BufferImpl.checkUpperBound throws IndexOutOfBoundsException with a message of the form "<index> + <size> > <length>" when a read primitive (getByte, getUnsignedByte, getInt, getIntLE, getUnsignedInt, getUnsignedIntLE, etc.) would access bytes beyond the buffer's writer index (its logical length), or when index/size arithmetic overflows to negative. This mirrors Netty's bounds checking: Buffers are length-bounded views over Netty buffers, and reading past the written data is an error rather than a zero-fill.

Source

Thrown at vertx-core/src/main/java/io/vertx/core/buffer/impl/BufferImpl.java:199

  public int getMediumLE(int pos) {
    checkUpperBound(pos, 3);
    return buffer.getMediumLE(pos);
  }

  public int getUnsignedMedium(int pos) {
    checkUpperBound(pos, 3);
    return buffer.getUnsignedMedium(pos);
  }

  public int getUnsignedMediumLE(int pos) {
    checkUpperBound(pos, 3);
    return buffer.getUnsignedMediumLE(pos);
  }

  private void checkUpperBound(int index, int size) {
    int length = buffer.writerIndex();
    if (index < 0 || index + size < 0 || index + size > length) {
      throw new IndexOutOfBoundsException(index + " + " + size + " > " + length);
    }
  }

  public byte[] getBytes() {
    byte[] arr = new byte[buffer.writerIndex()];
    buffer.getBytes(0, arr);
    return arr;
  }

  public byte[] getBytes(int start, int end) {
    Arguments.require(end >= start, "end must be greater or equal than start");
    byte[] arr = new byte[end - start];
    buffer.getBytes(start, arr, 0, end - start);
    return arr;
  }

  @Override
  public Buffer getBytes(byte[] dst) {

View on GitHub (pinned to fb308bd8c3)

Solutions

  1. Check bounds before reading: if (index + fieldSize > buffer.length()) handle/throw a descriptive parse error.
  2. Verify the buffer actually contains the expected bytes (e.g. from a truncated network read) before parsing.
  3. Fix the index computation so it never goes negative or overflows (use long arithmetic for the sum if indices can be large).

Example fix

// before
int value = buffer.getInt(offset); // throws if offset+4 > buffer.length()
// after
if (offset < 0 || offset + 4 > buffer.length()) {
  throw new IllegalStateException("truncated buffer: need " + (offset + 4) + " bytes, have " + buffer.length());
}
int value = buffer.getInt(offset);
Defensive patterns

Strategy: validation

Validate before calling

static void requireBytes(io.vertx.core.buffer.Buffer b, int index, int size) {
  if (index < 0 || index + size > b.length())
    throw new IllegalStateException("need bytes [" + index + "," + (index + size) + ") but buffer length is " + b.length());
}

Type guard

static boolean hasBytes(io.vertx.core.buffer.Buffer b, int index, int size) {
  return index >= 0 && size >= 0 && (long) index + size <= b.length();
}

Try / catch

try {
  int v = buffer.getInt(offset);
  parse(v);
} catch (IndexOutOfBoundsException e) {
  throw new ProtocolParseException("truncated frame at offset " + offset + ": " + e.getMessage(), e);
}

Prevention

When it happens

Trigger: buffer.getByte(i) with i >= buffer.length(); getInt(i) where i+4 exceeds length(); calls after the buffer was reset/truncated to a smaller size; negative index; or index+size overflowing int range with a huge index near Integer.MAX_VALUE.

Common situations: Parsing binary protocols with off-by-one or unvalidated length fields; reusing a buffer index computed for a previous (larger) packet; assuming get* zero-pads beyond the end like an array might; reading fixed-width fields at a variable offset without checking remaining bytes.

Related errors


AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06). Data as JSON: /api/errors/d7c3ccffa2a4c400. Report an issue: GitHub.