Stream: git-wasmtime

Topic: wasmtime / issue #14528 cargo installed wasmtime-cli "gdb...

view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2026 at 22:40):

mcclure opened issue #14528:

Test Case

In this directory are two WAST (textual wasm) files, and wasm files compiled from them with wabt wat2wasm:

https://data.runhello.com/j/wasm/bug-2026oct4/

Steps to Reproduce

  1. cargo install --features gdbstub wasmtime-cli

  2. Either download puzzle-start-invoke.wasm from the above link, or download puzzle-invoke.wast and compile it with wat2wasm --debug-names puzzle-invoke.wast -o puzzle-start-prebuilt.wasm.

  3. (Optional) Verify the wasm file runs without error, with wasmtime --invoke run puzzle-invoke-prebuilt.wasm. If it is working it will print the number 55312.

  4. Now, run the program in gdb server mode, by running wasmtime -g 8888 --invoke run puzzle-invoke-prebuilt.wasm.

Actual Results

It prints this

Error: expected at least one module field
     --> <built-in gdbstub>:1:1
      |
    1 |
      | ^

This message is both confusing (arrow pointing to unadorned "1") and seemingly inaccurate ("expected at least one module field", but there is a module).

But then it gets weirder. cargo install --force wasmtime-cli (force because it doesn't like binstalling over a source install) and rerun the above tests. With binstall instead of install, the test succeeds:

; wasmtime -g 8888 puzzle-start-prebuilt.wasm
Debugger: Debugger listening on 127.0.0.1:8888
Debugger: In LLDB, attach with: process connect --plugin wasm connect://127.0.0.1:8888

Expected Results

The -g run should have worked with the cargo installed version.

If there is some reason that the cargo installed version does not work— for example, a missing feature— then (1) the feature required for the binstall-like behavior should have been clearly documented (see also), and (2) the error message in the cargo install version should be clear enough to diagnose the problem and realize what feature I am missing.

Versions and Environment

source install: wasmtime 49.0.2
binary binstall: wasmtime 49.0.2 (3c8a3e79a 2026-10-02)
cargo 1.97.1
Debian GNU/Linux 13 (trixie)
AMD64

Extra Info

The test above uses the experimental --invoke feature. If you don't like that, puzzle-start.wast/puzzle-start-prebuilt.wasm in the same directory is built with a (start) section so that --invoke is not needed, you can just run wasmtime -g 1234 puzzle-start-prebuilt.wasm. It will not output anything however.

A friend testing with a believed-binstalled version of wasmtime 44.0.1 (f302ebd6b 2026-04-30) was able to confirm puzzle-start-prebuilt.wasm worked on my friend's Linux machine.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2026 at 22:40):

mcclure added the bug label to Issue #14528.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2026 at 22:57):

mcclure edited issue #14528:

Test Case

In this directory are two WAST (textual wasm) files, and wasm files compiled from them with wabt wat2wasm:

https://data.runhello.com/j/wasm/bug-2026oct4/

Steps to Reproduce

  1. cargo install --features gdbstub wasmtime-cli

  2. Either download puzzle-start-invoke.wasm from the above link, or download puzzle-invoke.wast and compile it with wat2wasm --debug-names puzzle-invoke.wast -o puzzle-start-prebuilt.wasm.

  3. (Optional) Verify the wasm file runs without error, with wasmtime --invoke run puzzle-invoke-prebuilt.wasm. If it is working it will print the number 55312.

  4. Now, run the program in gdb server mode, by running wasmtime -g 8888 --invoke run puzzle-invoke-prebuilt.wasm.

Actual Results

It prints this

Error: expected at least one module field
     --> <built-in gdbstub>:1:1
      |
    1 |
      | ^

This message is both confusing (arrow pointing to unadorned "1") and seemingly inaccurate ("expected at least one module field", but there is a module).

But then it gets weirder. cargo install --force wasmtime-cli (force because it doesn't like binstalling over a source install) and rerun the above tests. With binstall instead of install, the test succeeds:

; wasmtime -g 8888 puzzle-start-prebuilt.wasm
Debugger: Debugger listening on 127.0.0.1:8888
Debugger: In LLDB, attach with: process connect --plugin wasm connect://127.0.0.1:8888

Expected Results

The -g run should have worked with the cargo installed version.

If there is some reason that the cargo installed version does not work— for example, a missing feature— then (1) the feature required for the binstall-like behavior should have been clearly documented (see also), and (2) the error message in the cargo install version should be clear enough to diagnose the problem and realize what feature I am missing.

Versions and Environment

source install: wasmtime 49.0.2
binary binstall: wasmtime 49.0.2 (3c8a3e79a 2026-10-02)
cargo 1.97.1
Debian GNU/Linux 13 (trixie)
AMD64

Extra Info

The test above uses the experimental --invoke feature. If you don't like that, puzzle-start.wast/puzzle-start-prebuilt.wasm in the same directory is built with a (start) section so that --invoke is not needed, you can just run wasmtime -g 1234 puzzle-start-prebuilt.wasm. It will not output anything however.

A friend testing with a believed-binstalled version of wasmtime 44.0.1 (f302ebd6b 2026-04-30) was able to confirm puzzle-start-prebuilt.wasm worked on my friend's Linux machine.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2026 at 22:59):

mcclure edited issue #14528:

Test Case

In this directory are two WAST (textual wasm) files, and wasm files compiled from them with wabt wat2wasm:

https://data.runhello.com/j/wasm/bug-2026oct4/

Steps to Reproduce

  1. cargo install --features gdbstub wasmtime-cli

  2. Either download puzzle-start-invoke.wasm from the above link, or download puzzle-invoke.wast and compile it with wat2wasm --debug-names puzzle-invoke.wast -o puzzle-start-prebuilt.wasm.

  3. (Optional) Verify the wasm file runs without error, with wasmtime --invoke run puzzle-invoke-prebuilt.wasm. If it is working it will print the number 55312.

  4. Now, run the program in gdb server mode, by running wasmtime -g 8888 --invoke run puzzle-invoke-prebuilt.wasm.

Actual Results

It prints this

Error: expected at least one module field
     --> <built-in gdbstub>:1:1
      |
    1 |
      | ^

This message is both confusing (arrow pointing to unadorned "1") and seemingly inaccurate ("expected at least one module field", but there is a module).

But then it gets weirder. cargo binstall --force wasmtime-cli (force because it doesn't like binstalling over a source install) and rerun the above tests. With binstall instead of install, the test succeeds:

; wasmtime -g 8888 puzzle-start-prebuilt.wasm
Debugger: Debugger listening on 127.0.0.1:8888
Debugger: In LLDB, attach with: process connect --plugin wasm connect://127.0.0.1:8888

Expected Results

The -g run should have worked with the cargo installed version.

If there is some reason that the cargo installed version does not work— for example, a missing feature, or some attribute of the machine I built on— then (1) the feature or environment required for the binstall-like behavior should have been clearly documented (see also), and (2) the error message in the cargo install version should be clear enough to diagnose the problem and realize what I am missing.

Versions and Environment

source install: wasmtime 49.0.2
binary binstall: wasmtime 49.0.2 (3c8a3e79a 2026-10-02)
cargo 1.97.1
Debian GNU/Linux 13 (trixie)
AMD64

Extra Info

The test above uses the experimental --invoke feature. If you don't like that, puzzle-start.wast/puzzle-start-prebuilt.wasm in the same directory is built with a (start) section so that --invoke is not needed, you can just run wasmtime -g 1234 puzzle-start-prebuilt.wasm. It will not output anything however.

A friend testing with a believed-binstalled version of wasmtime 44.0.1 (f302ebd6b 2026-04-30) was able to confirm puzzle-start-prebuilt.wasm worked on my friend's Linux machine.

I tried the above tests with cargo install --locked instead of just cargo install and this changed nothing.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2026 at 23:27):

mcclure edited issue #14528:

Test Case

In this directory are two WAST (textual wasm) files, and wasm files compiled from them with wabt wat2wasm:

https://data.runhello.com/j/wasm/bug-2026oct4/

Steps to Reproduce

  1. cargo install --features gdbstub wasmtime-cli

  2. Either download puzzle-start-invoke.wasm from the above link, or download puzzle-invoke.wast and compile it with wat2wasm --debug-names puzzle-invoke.wast -o puzzle-start-prebuilt.wasm.

  3. (Optional) Verify the wasm file runs without error, with wasmtime --invoke run puzzle-invoke-prebuilt.wasm. If it is working it will print the number 55312.

  4. Now, run the program in gdb server mode, by running wasmtime -g 8888 --invoke run puzzle-invoke-prebuilt.wasm.

Actual Results

It prints this

Error: expected at least one module field
     --> <built-in gdbstub>:1:1
      |
    1 |
      | ^

This message is both confusing (arrow pointing to unadorned "1") and seemingly inaccurate ("expected at least one module field", but there is a module).

But then it gets weirder. cargo binstall --force wasmtime-cli (force because it doesn't like binstalling over a source install) and rerun the above tests. With binstall instead of install, the test succeeds:

; wasmtime -g 8888 puzzle-start-prebuilt.wasm
Debugger: Debugger listening on 127.0.0.1:8888
Debugger: In LLDB, attach with: process connect --plugin wasm connect://127.0.0.1:8888

Expected Results

The -g run should have worked with the cargo installed version.

If there is some reason that the cargo installed version does not work— for example, a missing feature, or some attribute of the machine I built on— then (1) the feature or environment required for the binstall-like behavior should have been clearly documented (see also), and (2) the error message in the cargo install version should be clear enough to diagnose the problem and realize what I am missing.

Versions and Environment

source install: wasmtime 49.0.2
binary binstall: wasmtime 49.0.2 (3c8a3e79a 2026-10-02)
cargo 1.97.1
Debian GNU/Linux 13 (trixie)
AMD64

Extra Info

The test above uses the experimental --invoke feature. If you don't like that, puzzle-start.wast/puzzle-start-prebuilt.wasm in the same directory is built with a (start) section so that --invoke is not needed, you can just run wasmtime -g 1234 puzzle-start-prebuilt.wasm. It will not output anything however.

A friend testing with a believed-binstalled version of wasmtime 44.0.1 (f302ebd6b 2026-04-30) was able to confirm puzzle-start-prebuilt.wasm worked on my friend's Linux machine.

I tried the above tests with cargo install --locked instead of just cargo install and this changed nothing.

I tried the above tests having wasmtime directly execute the wast files instead of building to wasm and this changed nothing.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 05 2026 at 15:22):

cfallin commented on issue #14528:

I believe what's going on here is that the fallback behavior in the gdbstub artifact crate includes an empty slice as the gdbstub adapter when we are not built in-tree (hence don't have access to the real build artifact).

That's the very confusing "Expected: at least one module field" -- parsing an empty string as a Wasm component (the internal gdbstub adapter component).

I don't remember exactly why we had to add this fallback; we went through many contortions on the build config (and I wish I had added a slightly more explanatory comment!). Probably what we should do is have an Option<&'static [u8]> and fail if -g is actually used in a build that didn't get the artifact. I'll see if I can make that change.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 05 2026 at 15:59):

mcclure commented on issue #14528:

Sure. To stress, the problem as I see it is not the failure per se, but rather that the error message is so misleading.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 05 2026 at 17:32):

cfallin closed issue #14528:

Test Case

In this directory are two WAST (textual wasm) files, and wasm files compiled from them with wabt wat2wasm:

https://data.runhello.com/j/wasm/bug-2026oct4/

Steps to Reproduce

  1. cargo install --features gdbstub wasmtime-cli

  2. Either download puzzle-start-invoke.wasm from the above link, or download puzzle-invoke.wast and compile it with wat2wasm --debug-names puzzle-invoke.wast -o puzzle-start-prebuilt.wasm.

  3. (Optional) Verify the wasm file runs without error, with wasmtime --invoke run puzzle-invoke-prebuilt.wasm. If it is working it will print the number 55312.

  4. Now, run the program in gdb server mode, by running wasmtime -g 8888 --invoke run puzzle-invoke-prebuilt.wasm.

Actual Results

It prints this

Error: expected at least one module field
     --> <built-in gdbstub>:1:1
      |
    1 |
      | ^

This message is both confusing (arrow pointing to unadorned "1") and seemingly inaccurate ("expected at least one module field", but there is a module).

But then it gets weirder. cargo binstall --force wasmtime-cli (force because it doesn't like binstalling over a source install) and rerun the above tests. With binstall instead of install, the test succeeds:

; wasmtime -g 8888 puzzle-start-prebuilt.wasm
Debugger: Debugger listening on 127.0.0.1:8888
Debugger: In LLDB, attach with: process connect --plugin wasm connect://127.0.0.1:8888

Expected Results

The -g run should have worked with the cargo installed version.

If there is some reason that the cargo installed version does not work— for example, a missing feature, or some attribute of the machine I built on— then (1) the feature or environment required for the binstall-like behavior should have been clearly documented (see also), and (2) the error message in the cargo install version should be clear enough to diagnose the problem and realize what I am missing.

Versions and Environment

source install: wasmtime 49.0.2
binary binstall: wasmtime 49.0.2 (3c8a3e79a 2026-10-02)
cargo 1.97.1
Debian GNU/Linux 13 (trixie)
AMD64

Extra Info

The test above uses the experimental --invoke feature. If you don't like that, puzzle-start.wast/puzzle-start-prebuilt.wasm in the same directory is built with a (start) section so that --invoke is not needed, you can just run wasmtime -g 1234 puzzle-start-prebuilt.wasm. It will not output anything however.

A friend testing with a believed-binstalled version of wasmtime 44.0.1 (f302ebd6b 2026-04-30) was able to confirm puzzle-start-prebuilt.wasm worked on my friend's Linux machine.

I tried the above tests with cargo install --locked instead of just cargo install and this changed nothing.

I tried the above tests having wasmtime directly execute the wast files instead of building to wasm and this changed nothing.

Last updated: Oct 11 2026 at 04:10 UTC