awslabs/llrt · critical

failed to decompress

Error message

failed to decompress

What it means

decompress() splits the embedded compressed payload into `parts` chunks and decompresses each via decompressPartial (in worker threads when parts > 1, inline otherwise). This error is raised when decompressPartial returns > 0 on the non-threaded (single-part) path, meaning one chunk failed to decompress. The payload is unusable and the runtime aborts before ever reaching user code.

Solutions

  1. Re-download or rebuild the llrt binary from a clean source; verify its checksum against the official release.
  2. Ensure no post-processing (antivirus quarantine/repair, code signers, binary patchers) altered the executable after build.
  3. If self-built, rebuild without modifying the binary after the bundle/append step, since offsets in readData depend on exact layout.
  4. Retry the download over a binary-safe channel (avoid ASCII transfer modes, proxies that rewrite content).
Defensive patterns

Strategy: validation

Validate before calling

// Validate the binary before running: compare against the published checksum.
import { createHash } from 'node:crypto';
import { readFileSync } from 'node:fs';
import { execFileSync } from 'node:child_process';
const sha = createHash('sha256').update(readFileSync('./llrt')).digest('hex');
if (sha !== EXPECTED_SHA256) throw new Error('llrt binary corrupted — decompression would fail');

Try / catch

try {
  child_process.execFileSync('./llrt', ['app.js']);
} catch (e) {
  if (e.status === 1 && /failed to decompress/.test(String(e.stderr))) {
    // re-download/reinstall the binary, then retry
  }
}

Prevention

When it happens

Trigger: decompressPartial returns a positive status for a chunk — the LZ4/zstd-compressed slice is corrupt, the inputSizes/outputSizes computed by readData don't match the actual data, the binary was modified/truncated after build (patching shifts the payload), or a build tool mis-embedded the compressed app.

Common situations: Binary corrupted by download over text/FTP mode, anivirus or signing tools rewriting the executable, post-build patching tools (e.g. rpath/editbin) changing file offsets, or a self-built llrt where the bundling step produced a mismatched size table.

Related errors


AI-assisted analysis of awslabs/llrt@742fc00b82 (2026-09-12). Data as JSON: /api/errors/43ac429edb28f314. Report an issue: GitHub.

Appendix: source

Thrown at llrt/src/main.c:232

  DecompressThreadArgs args[parts];
  for (uint32_t i = 0; i < parts; i++)
  {
    args[i].inputBuffer = compressedData + inputOffset;
    args[i].outputBuffer = uncompressed + outputOffset;
    args[i].srcSize = inputSizes[i];
    args[i].dstSize = outputSizes[i];
    args[i].id = i;
    inputOffset += inputSizes[i];
    outputOffset += outputSizes[i];
    if (parts > 1)
    {
      pthread_create(&threads[i], NULL, decompressPartial, (void *)&args[i]);
    }
    else
    {
      if (decompressPartial((void *)&args[i]) > 0)
      {
        err(1, "failed to decompress");
      }
    }
  }

  if (parts > 1)
  {
    for (uint8_t i = 0; i < parts; i++)
    {
      void *result;
      pthread_join(threads[i], &result);
    }
  }

  *uncompressedData = uncompressed;
}

int main(int argc, char *argv[])
{

View on GitHub (pinned to 742fc00b82)