prestodb/presto · error · OrcCorruptionException

Decoded value out of range for a 32bit number

Error message

Decoded value out of range for a 32bit number

What it means

next(int[], items) for INT (32-bit) columns decodes values via run-length reconstruction (repeatBase + (used + i) * delta) into a long, then narrows to int. If the long does not fit in 32 bits (narrowing changed the value), the underlying data violates the column's declared INT type. The library throws OrcCorruptionException rather than silently returning a wrapped/truncated value.

Source

Thrown at presto-orc/src/main/java/com/facebook/presto/orc/stream/LongInputStreamV1.java:137

    @Override
    public void next(int[] values, int items)
            throws IOException
    {
        int offset = 0;
        while (items > 0) {
            if (used == numValuesInRun) {
                numValuesInRun = 0;
                used = 0;
                readHeader();
            }

            int chunkSize = min(numValuesInRun - used, items);
            if (repeat) {
                for (int i = 0; i < chunkSize; i++) {
                    long literal = repeatBase + ((used + i) * delta);
                    int value = (int) literal;
                    if (literal != value) {
                        throw new OrcCorruptionException(input.getOrcDataSourceId(), "Decoded value out of range for a 32bit number");
                    }
                    values[offset + i] = value;
                }
            }
            else {
                for (int i = 0; i < chunkSize; i++) {
                    long literal = input.readVarint(signed);
                    int value = (int) literal;
                    if (literal != value) {
                        throw new OrcCorruptionException(input.getOrcDataSourceId(), "Decoded value out of range for a 32bit number");
                    }
                    values[offset + i] = value;
                }
            }
            used += chunkSize;
            offset += chunkSize;
            items -= chunkSize;
        }

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Verify the table/column schema matches the file: if values are genuinely 64-bit, change the column to BIGINT so the 64-bit decode path is used.
  2. Validate the ORC file with orc-tools; corrupt base/delta bytes indicate file damage — restore from backup.
  3. Confirm the reader's column mapping/orcSchema matches the writer's schema to avoid decoding the wrong stream with the wrong width.
  4. If the writer is buggy (emits out-of-range values for INT columns), fix or upgrade the writer.

Example fix

// before: column declared as INT in Hive/Presto but data written as BIGINT
CREATE TABLE t (v INT) STORED AS ORC; // fails: out of range for 32bit
// after
CREATE TABLE t (v BIGINT) STORED AS ORC;
Defensive patterns

Strategy: validation

Validate before calling

ColumnType expected = readSchemaType(orcFile, "my_col");
if (expected == ColumnType.LONG || expected == ColumnType.BIGINT) {
    // use the 64-bit read path; do not map this stream to int[]
    throw new SchemaMismatchException("my_col is BIGINT in file; cannot decode as int");
}

Type guard

// Java: no runtime narrowing possible silently — guard explicitly
static boolean fitsInt(long v) { return v >= Integer.MIN_VALUE && v <= Integer.MAX_VALUE; }
// use: if (!fitsInt(literal)) handleOverflow();

Try / catch

try {
    return intStream.next(values, items);
} catch (OrcCorruptionException e) {
    if (e.getMessage().contains("out of range for a 32bit number")) {
        LOG.error("Column declared INT contains 64-bit values; re-read as BIGINT");
        return bigIntReader.next(); // fall back to the wide-typed reader
    }
    throw e;
}

Prevention

When it happens

Trigger: next() called on a 32-bit LongInputStreamV1 where a run-mode literal repeatBase + (used + i) * delta overflows the int range — caused by corrupt delta/base bytes or wrong schema mapping (column actually encodes 64-bit values).

Common situations: Schema evolution mismatches (column declared INT in this reader's schema but written as BIGINT elsewhere), ORC files corrupted by bit-flips, or a reader interpreting the wrong column stream index after schema reordering.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/050a90f790321ae5. Report an issue: GitHub.