Skip to content

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

Open
@TerrorJack

Description

@TerrorJack

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    wasiIssues and PRs related to the WebAssembly System Interface.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions