wasmtime / issue #14794 wasi-preview1-component-adapter: ... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #14794 wasi-preview1-component-adapter: ...

Wasmtime GitHub notifications bot (Oct 17 2026 at 07:02):

The WASI preview1 component adapter traps with unreachable in Descriptors::open when a program opens a file while a few other files are still open, nested. As whitequark noted in the downstream report, the trap is probably this unreachable!: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/src/descriptors.rs#L310. Its message is also misleading: it should say that the freelist points to an open descriptor.

Downstream report, with the discussion: https://codeberg.org/YoWASP/yosys/issues/41 (YoWASP Yosys: Yosys + ABC compiled to WASI, adapted to a component with the preview1 adapter, and run in Node through jco).

Reproduction

@yowasp/yosys 0.68.1207 and 0.70.1258, Node 25:
import { runYosys } from '@yowasp/yosys';

const files = {
  't.v': 'module top(input a, b, c, output y); assign y = (a & b) | c; endmodule\n',
  'lut.lib': '1 1 1\n2 1 1\n3 1 1\n4 1 1\n',
  'x.abc': 'read_lut lut.lib\n',
};
// traps: RuntimeError: unreachable
await runYosys(['-p', 'read_verilog t.v; proc; techmap; abc -script x.abc'], files);
// works: the same command given inline
await runYosys(['-p', 'read_verilog t.v; proc; techmap; abc -script +read_lut,lut.lib;strash;if'], files);
The two calls differ in nesting. In the first, Yosys's ABC script sources x.abc, whose file is still open, and read_lut then calls fopen on lut.lib. In the second there is one source level less, and the same fopen works. A missing file (read_lut nothing.lib) gives ABC's normal "Cannot open input file" error, not a trap. Native Yosys runs both without error.

Backtrace (Node, @yowasp/yosys 0.70.1258)
RuntimeError: unreachable
    at _ZN22wasi_snapshot_preview111descriptors11Descriptors4open17hf43b776c170aa288E (wasm://wasm/00021de6:wasm-function[102]:0x4cac)
    at path_open (wasm://wasm/00021de6:wasm-function[78]:0x3472)
    at wasm://wasm/c8fd64d6:wasm-function[18]:0x317
    at yosys.wasm.__wasi_path_open (wasm-function[46148]:0x2875534)
    at yosys.wasm.__wasilibc_nocwd_openat_nomode (wasm-function[46157]:0x28756da)
    at yosys.wasm.__wasilibc_open_nomode (wasm-function[46174]:0x287620a)
    at yosys.wasm.fopen (wasm-function[46359]:0x28816ad)
    at yosys.wasm.abc::If_CommandReadLut(abc::Abc_Frame_t_*, int, char**) (wasm-function[23010]:0x1828002)
    at yosys.wasm.abc::CmdCommandDispatch(...)
    at yosys.wasm.abc::Cmd_CommandExecute(...)
    at yosys.wasm.abc::CmdCommandSource(abc::Abc_Frame_t_*, int, char**) (wasm-function[19831]:0x14b75c8)
    at yosys.wasm.abc::CmdCommandDispatch(...)
    at yosys.wasm.abc::Cmd_CommandExecute(...)
    at yosys.wasm.abc::CmdCommandSource(abc::Abc_Frame_t_*, int, char**) (wasm-function[19831]:0x14b75c8)
    at yosys.wasm.abc::CmdCommandDispatch(...)
    at yosys.wasm.abc::Cmd_CommandExecute(...)
    at yosys.wasm.abc::Abc_RealMain(int, char**) (wasm-function[21311]:0x1618f7e)
    at yosys.wasm.(anonymous namespace)::RunAbcState::run(...)
    at yosys.wasm.(anonymous namespace)::AbcPass::execute(...)
    at yosys.wasm.Yosys::Pass::call(...)
    at yosys.wasm.Yosys::run_pass(...)
    at yosys.wasm.main (wasm-function[4355]:0x3e41d4)
    at yosys.wasm._start (wasm-function[30]:0x12624)
    at wasi:cli/run@0.2.3#run (wasm://wasm/00021de6:wasm-function[51]:0xdba)
I don't know which adapter version YoWASP's build uses. It is reproducible with the published npm packages above. A downstream workaround exists (passing the commands inline), so this is not urgent for us. Still, the trap and its message look like an adapter bug in the descriptor freelist's bookkeeping when files are opened and closed in this nested pattern.

Wasmtime GitHub notifications bot (Oct 18 2026 at 17:33):

alexcrichton commented on issue #14794:

Without diving too deeply here you may be affected by #11277 perhaps. Can you try updating jco which updates the adapter to see if that fixes things?

Wasmtime GitHub notifications bot (Oct 18 2026 at 18:31):

pmnmalo commented on issue #14794:

Thanks! @yowasp/yosys 0.70.1258, where this reproduces, is built with jco new --wasi-command from @bytecodealliance/jco 1.19.0 (released 2026-04-22; see the package's transpile script), so its adapter should already include #11277 (merged 2025-07-18). The trap reproduces with that package as published. Unless the adapter jco 1.19.0 embeds predates that fix, this looks like a separate case. Is there a newer adapter build I could try, or a way to check which adapter version a component embeds?

Wasmtime GitHub notifications bot (Oct 18 2026 at 18:32):

pmnmalo commented on issue #14794:

For context on our side: we have a workaround, so nothing is blocked. Our tool (Silinx, an FPGA IDE that runs YoWASP Yosys in the browser and in Node) gives ABC its script inline instead of from a file: abc -script +read_lut,lut.lib;strash;dc2;… rather than abc -script x.abc with read_lut lut.lib inside x.abc. Yosys then has one source level less, so read_lut's fopen happens while fewer files are open, and the trap doesn't occur. The script and its LUT library are the same either way; only how they reach ABC changes.

A permanent fix would still be great to have: reading a script from a file is ABC's usual way, and other YoWASP users will hit the trap with nothing pointing them to the inline form. I'm glad to test a newer adapter build against the reproduction above.

Wasmtime GitHub notifications bot (Oct 19 2026 at 14:21):

alexcrichton commented on issue #14794:

IIRC jco updated its adapter pretty recently, so I think if that's built with jco 1.19 it may still be worth trying to update. I'm not entirely certain though, but if you can I think it'd be worth a shot

Wasmtime GitHub notifications bot (Oct 20 2026 at 07:16):

pmnmalo commented on issue #14794:

Thanks, that makes sense: jco is at 1.39.0 now, so 1.19.0's adapter is a lot of releases behind. I can't easily rebuild the component on our side, because the npm package ships only the transpiled output, not the yosys.wasm core module that jco new takes. The rebuild fits best in YoWASP's build, where that module exists. I'll mention it on the YoWASP issue (codeberg.org/YoWASP/yosys/issues/41) so it can be tried with a current jco. If the trap is gone there, this can be closed; if not, I'll come back here with what it shows.

Wasmtime GitHub notifications bot (Oct 22 2026 at 17:16):

pmnmalo commented on issue #14794:

Update: the reproduction above no longer traps with YoWASP's new build, @yowasp/yosys 0.71.188-dev.1267 (published today), which is built with a current adapter/jco. With the same script on Node 25, 0.70.1258 still gives RuntimeError: unreachable on the nested abc -script x.abc call, and 0.71.188-dev.1267 runs it. So it looks fixed by the newer adapter. Thanks! Feel free to close this, unless you want to keep it for the misleading unreachable! message in Descriptors::open.

Wasmtime GitHub notifications bot (Oct 22 2026 at 17:18):

alexcrichton closed issue #14794:

The WASI preview1 component adapter traps with unreachable in Descriptors::open when a program opens a file while a few other files are still open, nested. As whitequark noted in the downstream report, the trap is probably this unreachable!: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/src/descriptors.rs#L310. Its message is also misleading: it should say that the freelist points to an open descriptor.

Downstream report, with the discussion: https://codeberg.org/YoWASP/yosys/issues/41 (YoWASP Yosys: Yosys + ABC compiled to WASI, adapted to a component with the preview1 adapter, and run in Node through jco).

Reproduction

@yowasp/yosys 0.68.1207 and 0.70.1258, Node 25:
import { runYosys } from '@yowasp/yosys';

const files = {
  't.v': 'module top(input a, b, c, output y); assign y = (a & b) | c; endmodule\n',
  'lut.lib': '1 1 1\n2 1 1\n3 1 1\n4 1 1\n',
  'x.abc': 'read_lut lut.lib\n',
};
// traps: RuntimeError: unreachable
await runYosys(['-p', 'read_verilog t.v; proc; techmap; abc -script x.abc'], files);
// works: the same command given inline
await runYosys(['-p', 'read_verilog t.v; proc; techmap; abc -script +read_lut,lut.lib;strash;if'], files);
The two calls differ in nesting. In the first, Yosys's ABC script sources x.abc, whose file is still open, and read_lut then calls fopen on lut.lib. In the second there is one source level less, and the same fopen works. A missing file (read_lut nothing.lib) gives ABC's normal "Cannot open input file" error, not a trap. Native Yosys runs both without error.

Backtrace (Node, @yowasp/yosys 0.70.1258)
RuntimeError: unreachable
    at _ZN22wasi_snapshot_preview111descriptors11Descriptors4open17hf43b776c170aa288E (wasm://wasm/00021de6:wasm-function[102]:0x4cac)
    at path_open (wasm://wasm/00021de6:wasm-function[78]:0x3472)
    at wasm://wasm/c8fd64d6:wasm-function[18]:0x317
    at yosys.wasm.__wasi_path_open (wasm-function[46148]:0x2875534)
    at yosys.wasm.__wasilibc_nocwd_openat_nomode (wasm-function[46157]:0x28756da)
    at yosys.wasm.__wasilibc_open_nomode (wasm-function[46174]:0x287620a)
    at yosys.wasm.fopen (wasm-function[46359]:0x28816ad)
    at yosys.wasm.abc::If_CommandReadLut(abc::Abc_Frame_t_*, int, char**) (wasm-function[23010]:0x1828002)
    at yosys.wasm.abc::CmdCommandDispatch(...)
    at yosys.wasm.abc::Cmd_CommandExecute(...)
    at yosys.wasm.abc::CmdCommandSource(abc::Abc_Frame_t_*, int, char**) (wasm-function[19831]:0x14b75c8)
    at yosys.wasm.abc::CmdCommandDispatch(...)
    at yosys.wasm.abc::Cmd_CommandExecute(...)
    at yosys.wasm.abc::CmdCommandSource(abc::Abc_Frame_t_*, int, char**) (wasm-function[19831]:0x14b75c8)
    at yosys.wasm.abc::CmdCommandDispatch(...)
    at yosys.wasm.abc::Cmd_CommandExecute(...)
    at yosys.wasm.abc::Abc_RealMain(int, char**) (wasm-function[21311]:0x1618f7e)
    at yosys.wasm.(anonymous namespace)::RunAbcState::run(...)
    at yosys.wasm.(anonymous namespace)::AbcPass::execute(...)
    at yosys.wasm.Yosys::Pass::call(...)
    at yosys.wasm.Yosys::run_pass(...)
    at yosys.wasm.main (wasm-function[4355]:0x3e41d4)
    at yosys.wasm._start (wasm-function[30]:0x12624)
    at wasi:cli/run@0.2.3#run (wasm://wasm/00021de6:wasm-function[51]:0xdba)
I don't know which adapter version YoWASP's build uses. It is reproducible with the published npm packages above. A downstream workaround exists (passing the commands inline), so this is not urgent for us. Still, the trap and its message look like an adapter bug in the descriptor freelist's bookkeeping when files are opened and closed in this nested pattern.

Last updated: Oct 31 2026 at 23:03 UTC