wasi fast calls causes segfault on x86_64-linux when running a wasm32-wasi module

@devsnek

Version

v22.2.0

Platform

Linux build01 6.7.9 #1-NixOS SMP PREEMPT_DYNAMIC Wed Mar 6 14:54:01 UTC 2024 x86_64 GNU/Linux

Subsystem

wasi

What steps will reproduce the bug?

https://files.catbox.moe/izkaki.zst

The above .tar.zst tarball contains openFile008.wasm and wasm-run.mjs in the same directory. openFile008.wasm is a Haskell program compiled from this file that simply creates a temporary directory, then opens/closes some empty files within it. wasm-run.mjs is a script to run it:

#!/usr/bin/env -S node --no-warnings --experimental-wasi-unstable-preview1

import fs from "node:fs/promises";
import { WASI } from "node:wasi";

const wasi = new WASI({
  version: "preview1",
  args: ["openFile008.wasm"],
  env: { PATH: "" },
  preopens: { "/": process.cwd() },
  returnOnExit: false,
});

const instance = (
  await WebAssembly.instantiate(await fs.readFile("openFile008.wasm"), {
    wasi_snapshot_preview1: wasi.wasiImport,
  })
).instance;

wasi.start(instance);

Now, simply run the script above.

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior? Why is that the expected behavior?

It should quickly run to completion without any issue. This is the expected behavior you get by running it with wasmtime run .::/ -- openFile008.wasm, or using node v18 to run the repro script.

What do you see instead?

node process segfaults.

Additional information

I have tried to bisect this breakage on the main branch. The offending commit is b3bf07e that landed #43697. cc @devsnek

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Still reproduces on current Node (v22.23.2, x64), with a real interpreter workload (WASI-compiled CPython) rather than a synthetic test — full details and backtraces posted on #46777, which has the root-cause diagnosis (AdjustAmountOfExternalAllocatedMemory triggering GC from inside the fast call). One addition: this isn't purely x86_64-vs-arm64 — I could not reproduce it on either native macOS arm64 or a linux/amd64 container running under QEMU on Apple Silicon, only on real x86_64 hardware (GitHub Actions' hosted runner).

fix: require Node 24+ for the wasm backend on Linux

fix: require Node 24+ for the wasm backend on Linux (#5)

Navigation Menu

Repository navigation

wasi fast calls causes segfault on x86_64-linux when running a wasm32-wasi module #53087

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

wasi fast calls causes segfault on x86_64-linux when running a wasm32-wasi module #53087

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

github-actions commented on May 21, 2026

github-actions commented on Jun 21, 2026

jonheltonbloom commented on Aug 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions