MuntashirAkon/AppManager · error · IOException

Corrupted input, " + name + " value too big

Error message

Corrupted input, " + name + " value too big

What it means

The counterpart of the negative-value check in checkBounds: a field decoded from the bzip2 bitstream exceeded its exclusive limit (e.g. nGroups > 6, alphaSize > MAX_ALPHA_SIZE, tt index beyond table length). Valid bzip2 encoders never emit such values, so this signals corrupted or maliciously crafted input.

Source

Thrown at app/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorInputStream.java:395

    private static boolean bsGetBit(final BitInputStream bin) throws IOException {
        return bsR(bin, 1) != 0;
    }

    private static char bsGetUByte(final BitInputStream bin) throws IOException {
        return (char) bsR(bin, 8);
    }

    private static int bsGetInt(final BitInputStream bin) throws IOException {
        return bsR(bin, 32);
    }

    private static void checkBounds(final int checkVal, final int limitExclusive, final String name)
            throws IOException {
        if (checkVal < 0) {
            throw new IOException("Corrupted input, " + name + " value negative");
        }
        if (checkVal >= limitExclusive) {
            throw new IOException("Corrupted input, " + name + " value too big");
        }
    }

    /**
     * Called by createHuffmanDecodingTables() exclusively.
     */
    private static void hbCreateDecodeTables(final int[] limit,
                                             final int[] base, final int[] perm, final char[] length,
                                             final int minLen, final int maxLen, final int alphaSize)
            throws IOException {
        for (int i = minLen, pp = 0; i <= maxLen; i++) {
            for (int j = 0; j < alphaSize; j++) {
                if (length[j] == i) {
                    perm[pp++] = j;
                }
            }
        }

View on GitHub (pinned to 0152f468fc)

Solutions

  1. Verify the archive with `bzip2 -t` or re-download; the data is corrupt.
  2. Check you are not feeding the wrong format into BZip2CompressorInputStream.
  3. Wrap decompression in try-catch IOException and fail gracefully; never ignore, as output would be wrong.
  4. If input comes from untrusted users, treat this as an expected rejection path (library is defending against CVE-style overflows).

Example fix

// before
byte[] data = decompress(untrustedBytes); // throws raw IOException
// after
try {
    data = decompress(untrustedBytes);
} catch (IOException e) {
    throw new InvalidArchiveException("corrupt bzip2 input: " + e.getMessage(), e);
}
Defensive patterns

Strategy: try-catch

Try / catch

try {
    decompress(in);
} catch (IOException e) {
    throw new InvalidArchiveException("bzip2 bounds violation (corrupt data): " + e.getMessage(), e);
}

Prevention

When it happens

Trigger: BZip2CompressorInputStream.read() while decompressing a block whose decoded field (nGroups, nSelectors, alphaSize, tt index, yy, nextSym, lastShadow) is >= the limit passed to checkBounds.

Common situations: Corrupted/truncated archives, crafted 'zip bomb' style inputs, wrong decoder applied to non-bzip2 bytes, disk or network bit errors, fuzzed/security-test inputs.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

AI-assisted analysis of MuntashirAkon/AppManager@0152f468fc (2026-09-12). Data as JSON: /api/errors/3c9a211098f3fd26. Report an issue: GitHub.