What causes "Failed to unmap memory" in awslabs/llrt?

Run an unmodified official llrt binary — this failure indicates corrupted internal state, so rebuild cleanly from source.

awslabs/llrt · error

Failed to unmap memory

Error message

Failed to unmap memory

What it means

After the decompressed runtime has been fully written into the memfd mapping and executed-pending, main() calls munmap(uncompressedData, uncompressedSize) to release the mapping. This error means munmap returned -1. By this point extraction succeeded, so it signals address-space bookkeeping trouble rather than payload problems; the runtime still aborts with exit code 1.

Solutions

Run an unmodified official llrt binary — this failure indicates corrupted internal state, so rebuild cleanly from source.
Remove LD_PRELOAD interposers, sanitizers (ASAN/VALGRIND wrappers), or seccomp-notify tools that intercept mmap/munmap.
Check `dmesg`/strace output (`strace -f -e trace=mmap,munmap,llrt-binary`) to see the exact EINVAL/errno munmap returned.
Report the bug with the llrt version, kernel version, and strace log if it reproduces on a stock build.

Defensive patterns

Strategy: try-catch

Try / catch

// Not preventable from outside; detect at supervisor level:
try {
  child_process.execFileSync('./llrt', ['app.js']);
} catch (e) {
  if (e.status === 1 && /Failed to unmap memory/.test(String(e.stderr))) {
    // rebuild from clean source / remove mmap-mutating interposers
  }
}

Prevention

Use official, unmodified llrt binaries — this error signals broken internal state.
Avoid LD_PRELOAD hooks or sanitizers that interpose mmap/munmap around the runtime.
If reproducible on a stock build, capture strace output and file a bug with kernel/version details.
Pin a known-good llrt release instead of custom-patched builds.

When it happens

Trigger: munmap fails because the (pointer, length) pair is not a valid mapping — practically only if decompress() returned a pointer/size inconsistent with the mmap done earlier (internal state bug), or if another thread/component already unmapped or altered the region. Address-length mismatch (size not matching the mapped extent) is the typical cause.

Common situations: Encountered only when llrt's own invariants are broken: a custom-patched build changed mmap flags (e.g. MAP_NORESERVE with alignment tricks), or someone instrumented/intercepted mmap/munmap (LD_PRELOAD, sanitizers) causing mismatched unmap calls.

Related errors

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

Appendix: source

Thrown at llrt/src/main.c:277

  int outputFd = memfd_create_syscall(appname, 0);
  if (outputFd == -1)
  {
    err(1, "Could not create memfd");
  }

  char *uncompressedData;
  uint32_t uncompressedSize;

  decompress(&uncompressedData, &uncompressedSize, outputFd);

  double t1 = micro_seconds();
  logInfo("Runtime starting\n");
  logInfo("Extraction time: %10.4f ms\n", (t1 - t0) / 1000.0);

  if (munmap(uncompressedData, uncompressedSize) == -1)
  {
    err(1, "Failed to unmap memory");
  }

  double t2 = micro_seconds();
  logInfo("Extraction + write time: %10.4f ms\n", (t2 - t0) / 1000.0);

  char **new_argv = malloc((size_t)(argc + 1) * sizeof *new_argv);
  for (uint8_t i = 0; i < argc; ++i)
  {
    if (i == 0)
    {
      size_t length = strlen(appname) + 2;
      new_argv[i] = malloc(length);
      memcpy(new_argv[i], "/", 1);
      memcpy(new_argv[i] + 1, appname, length);
      setenv("_", new_argv[i], true);
    }
    else
    {

View on GitHub (pinned to 742fc00b82)