What causes "invalid entry crc-32" in prestodb/presto?

Mask computed CRCs to unsigned 32-bit before storing: entry.setCrc(crcValue & 0xffffffffL).

prestodb/presto · error · IllegalArgumentException

invalid entry crc-32

Error message

invalid entry crc-32

What it means

ZipFileEntry.setCrc validates that a CRC-32 value fits in the unsigned 32-bit range [0, 0xffffffff] because the ZIP format stores CRC-32 in a 4-byte field. A negative or oversized value cannot come from well-formed central directory bytes and indicates a parsing or computation bug, so it throws IllegalArgumentException.

Source

Thrown at presto-druid/src/main/java/com/facebook/presto/druid/zip/ZipFileEntry.java:195

    public String getName()
    {
        return name;
    }

    public void setTime(long time)
    {
        this.time = time;
    }

    public long getTime()
    {
        return time;
    }

    public void setCrc(long crc)
    {
        if (crc < 0 || crc > 0xffffffffL) {
            throw new IllegalArgumentException("invalid entry crc-32");
        }
        this.crc = crc;
    }

    public long getCrc()
    {
        return crc;
    }

    public void setSize(long size)
    {
        if (size < 0) {
            throw new IllegalArgumentException("invalid entry size");
        }
        if (size > 0xffffffffL) {
            featureSet.add(Feature.ZIP64_SIZE);
        }
        else {

View on GitHub (pinned to 55bb57d202)

Solutions

Mask computed CRCs to unsigned 32-bit before storing: entry.setCrc(crcValue & 0xffffffffL).
Verify the zip entry header bytes are not corrupt; re-ingest the segment if so.
Check any custom writer offsets against the CentralDirectoryFileHeader layout (CRC at offset 16).
Run `unzip -t` on the archive to confirm the stored CRCs are valid.

Example fix

// before
entry.setCrc(crc32.getValue()); // if crc32.getValue() typed as int/negative long path
// after
long crc = crc32.getValue() & 0xffffffffL;
entry.setCrc(crc);

Defensive patterns

Strategy: validation

Validate before calling

long crc = crc32.getValue() & 0xffffffffL;
if (crc < 0 || crc > 0xffffffffL) {
    throw new IllegalArgumentException("CRC out of unsigned 32-bit range");
}
entry.setCrc(crc);

Try / catch

try {
    entry.setCrc(rawValue);
} catch (IllegalArgumentException e) {
    if (e.getMessage().equals("invalid entry crc-32")) {
        entry.setCrc(rawValue & 0xffffffffL);
    } else {
        throw e;
    }
}

Prevention

Always mask CRC values with 0xffffffffL before storing in zip entries.
Never assign CRC fields from signed ints without masking.
Validate entry headers when parsing custom zip formats.

When it happens

Trigger: setCrc() called (via read) with a value < 0 or > 0xffffffffL — typically from misparsed fixed-size data (wrong offsets/corrupt header) or code that computes/stores the CRC incorrectly (e.g., signed int interpreted as negative).

Common situations: Corrupt central directory entries, byte-offset bugs when reading fixed-size data, or application code that does `int crc = ...; entry.setCrc(crc)` where a negative signed int leaks through instead of being masked with 0xffffffffL.

Related errors

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