wasmtime / issue #14609 wasmtime -g panics on wasm file f... · git-wasmtime · Zulip Chat Archive

Stream: git-wasmtime

Topic: wasmtime / issue #14609 wasmtime -g panics on wasm file f...

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:50):

mcclure opened issue #14609:

Test Case

See this directory . It contains two .wasm files and the .wast files used to build them. Both export a single "run" function; the only difference is that "puzzle-invoke", "run" returns a number (6) and "puzzle" "run" returns nothing and furthermore is marked as the (start) function.

Steps to Reproduce

In terminal 1, run wasmtime -g 1234 -D debug-info -O opt-level=0 puzzle.wasm . In terminal 2, run lldb, then process connect --plugin wasm connect://127.0.0.1:1234. On connection, type "c".

Actual Results

The moment lldb runs "continue", wasmtime exits with a Rust panic!.

For me, wasmtime side:

<img width="1658" height="1218" alt="Image" src="https://github.com/user-attachments/assets/4a2644f9-b800-49f9-a332-3ed525bd8376" />

lldb side:

<img width="1102" height="480" alt="Image" src="https://github.com/user-attachments/assets/e3203e8e-d0cf-499f-b3d8-8402d04e8c6e" />

Expected Results

puzzle-invoke.wasm and puzzle.wasm should behave identically (other than -invoke's added return value). Additionally, if wasmtime puzzle.wasm works (it does), then wasmtime puzzle.wasm should work equally well. Additionally, literally nothing I can do should result in wasmtime exiting with a panic; even malformed wasm (which I do not believe puzzle.wasm is) should result in a human-readable error message.

Versions and Environment

wat2wasm --version
1.0.36

wasmtime --version
wasmtime 49.0.2 (3c8a3e79a 2026-10-02)

lldb --version
lldb version 19.1.7

lsb-release -a
Description: Debian GNU/Linux 13 (trixie)

AMD64

Extra Info

Some additional oddities:

The version without a (start) section— "puzzle-invoke"— does not crash.

The difference is the (start) section, not --invoke. As in how-to-run.txt at the link, running "puzzle" with the --invoke run flag also crashes.

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:50):

mcclure added the bug label to Issue #14609.

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:52):

mcclure edited issue #14609:

Test Case

See this directory . It contains two .wasm files and the .wast files used to build them. Both export a single "run" function; the only difference is that "puzzle-invoke", "run" returns a number (6) and "puzzle" "run" returns nothing and furthermore is marked as the (start) function.

Steps to Reproduce

In terminal 1, run wasmtime -g 1234 -D debug-info -O opt-level=0 puzzle.wasm . In terminal 2, run lldb, then process connect --plugin wasm connect://127.0.0.1:1234. On connection, type "c".

Actual Results

The moment lldb runs "continue", wasmtime exits with a Rust panic!.

For me, wasmtime side:

<img width="1658" height="1218" alt="Image" src="https://github.com/user-attachments/assets/4a2644f9-b800-49f9-a332-3ed525bd8376" />

lldb side:

<img width="1102" height="480" alt="Image" src="https://github.com/user-attachments/assets/e3203e8e-d0cf-499f-b3d8-8402d04e8c6e" />

Expected Results

puzzle-invoke.wasm and puzzle.wasm should behave identically (other than -invoke's added return value). Additionally, if wasmtime puzzle.wasm works (it does), then wasmtime puzzle.wasm should work equally well. Additionally, literally nothing I can do should result in wasmtime exiting with a panic; even malformed wasm (which I do not believe puzzle.wasm is) should result in a human-readable error message.

Versions and Environment
wat2wasm --version
1.0.36

wasmtime --version
wasmtime 49.0.2 (3c8a3e79a 2026-10-02)

lldb --version
lldb version 19.1.7

lsb-release -a
Description:    Debian GNU/Linux 13 (trixie)
``

AMD64

### Extra Info

Some additional oddities:

* The version without a (start) section— "puzzle-invoke"— does not crash.
* The difference is the (start) section, *not* --invoke. As in how-to-run.txt at the link, running "puzzle" with the --invoke run flag also crashes.
````

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:52):

mcclure edited issue #14609:

Test Case

See this directory . It contains two .wasm files and the .wast files used to build them. Both export a single "run" function; the only difference is that "puzzle-invoke", "run" returns a number (6) and "puzzle" "run" returns nothing and furthermore is marked as the (start) function.

Steps to Reproduce

In terminal 1, run wasmtime -g 1234 -D debug-info -O opt-level=0 puzzle.wasm . In terminal 2, run lldb, then process connect --plugin wasm connect://127.0.0.1:1234. On connection, type "c".

Actual Results

The moment lldb runs "continue", wasmtime exits with a Rust panic!.

For me, wasmtime side:

<img width="1102" height="480" alt="Image" src="https://github.com/user-attachments/assets/e3203e8e-d0cf-499f-b3d8-8402d04e8c6e" />

lldb side:

<img width="1658" height="1218" alt="Image" src="https://github.com/user-attachments/assets/4a2644f9-b800-49f9-a332-3ed525bd8376" />

Expected Results

puzzle-invoke.wasm and puzzle.wasm should behave identically (other than -invoke's added return value). Additionally, if wasmtime puzzle.wasm works (it does), then wasmtime puzzle.wasm should work equally well. Additionally, literally nothing I can do should result in wasmtime exiting with a panic; even malformed wasm (which I do not believe puzzle.wasm is) should result in a human-readable error message.

Versions and Environment
wat2wasm --version
1.0.36

wasmtime --version
wasmtime 49.0.2 (3c8a3e79a 2026-10-02)

lldb --version
lldb version 19.1.7

lsb-release -a
Description:    Debian GNU/Linux 13 (trixie)
``

AMD64

### Extra Info

Some additional oddities:

* The version without a (start) section— "puzzle-invoke"— does not crash.
* The difference is the (start) section, *not* --invoke. As in how-to-run.txt at the link, running "puzzle" with the --invoke run flag also crashes.
````

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:53):

mcclure edited issue #14609:

Test Case

See this directory . It contains two .wasm files and the .wast files used to build them. Both export a single "run" function; the only difference is that "puzzle-invoke", "run" returns a number (6) and "puzzle" "run" returns nothing and furthermore is marked as the (start) function.

Steps to Reproduce

In terminal 1, run wasmtime -g 1234 -D debug-info -O opt-level=0 puzzle.wasm . In terminal 2, run lldb, then process connect --plugin wasm connect://127.0.0.1:1234. On connection, type "c".

Actual Results

The moment lldb runs "continue", wasmtime exits with a Rust panic!. For me, the panic is 100% consistent and identical every time.

For me, wasmtime side:

<img width="1102" height="480" alt="Image" src="https://github.com/user-attachments/assets/e3203e8e-d0cf-499f-b3d8-8402d04e8c6e" />

lldb side:

<img width="1658" height="1218" alt="Image" src="https://github.com/user-attachments/assets/4a2644f9-b800-49f9-a332-3ed525bd8376" />

Expected Results

puzzle-invoke.wasm and puzzle.wasm should behave identically (other than -invoke's added return value). Additionally, if wasmtime puzzle.wasm works (it does), then wasmtime puzzle.wasm should work equally well. Additionally, literally nothing I can do should result in wasmtime exiting with a panic; even malformed wasm (which I do not believe puzzle.wasm is) should result in a human-readable error message.

Versions and Environment
wat2wasm --version
1.0.36

wasmtime --version
wasmtime 49.0.2 (3c8a3e79a 2026-10-02)

lldb --version
lldb version 19.1.7

lsb-release -a
Description:    Debian GNU/Linux 13 (trixie)
``

AMD64

### Extra Info

Some additional oddities:

* The version without a (start) section— "puzzle-invoke"— does not crash.
* The difference is the (start) section, *not* --invoke. As in how-to-run.txt at the link, running "puzzle" with the --invoke run flag also crashes.
````

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:54):

mcclure edited issue #14609:

Test Case

See this directory . It contains two .wasm files and the .wast files used to build them. Both export a single "run" function; the only difference is that "puzzle-invoke", "run" returns a number (6) and "puzzle" "run" returns nothing and furthermore is marked as the (start) function.

Steps to Reproduce

In terminal 1, run wasmtime -g 1234 -D debug-info -O opt-level=0 puzzle.wasm . In terminal 2, run lldb, then process connect --plugin wasm connect://127.0.0.1:1234. On connection, type "c".

Actual Results

The moment lldb runs "continue", wasmtime exits with a Rust panic!. For me, the panic is 100% consistent and identical every time.

For me, wasmtime side:

<img width="1102" height="480" alt="Image" src="https://github.com/user-attachments/assets/e3203e8e-d0cf-499f-b3d8-8402d04e8c6e" />

lldb side:

<img width="1658" height="1218" alt="Image" src="https://github.com/user-attachments/assets/4a2644f9-b800-49f9-a332-3ed525bd8376" />

Expected Results

puzzle-invoke.wasm and puzzle.wasm should behave identically (other than -invoke's added return value). Additionally, if wasmtime puzzle.wasm works (it does), then wasmtime puzzle.wasm should work equally well. Additionally, literally nothing I can do should result in wasmtime exiting with a panic; even malformed wasm (which I do not believe puzzle.wasm is) should result in a human-readable error message.

Versions and Environment
wat2wasm --version
1.0.36

wasmtime --version
wasmtime 49.0.2 (3c8a3e79a 2026-10-02)

lldb --version
lldb version 19.1.7

lsb-release -a
Description:    Debian GNU/Linux 13 (trixie)
AMD64

Extra Info

Some additional oddities:

The version without a (start) section— "puzzle-invoke"— does not crash.

The difference is the (start) section, not --invoke. As in how-to-run.txt at the link, running "puzzle" with the --invoke run flag also crashes.

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:55):

alexcrichton added the wasmtime:debugging label to Issue #14609.

Wasmtime GitHub notifications bot (Oct 07 2026 at 18:57):

mcclure edited issue #14609:

Test Case

See this directory . It contains two .wasm files and the .wast files used to build them. Both export a single "run" function; the only difference is that "puzzle-invoke", "run" returns a number (6) and "puzzle" "run" returns nothing and furthermore is marked as the (start) function.

Steps to Reproduce

In terminal 1, run wasmtime -g 1234 -D debug-info -O opt-level=0 puzzle.wasm . In terminal 2, run lldb, then process connect --plugin wasm connect://127.0.0.1:1234. On connection, type "c".

Actual Results

The moment lldb runs "continue", wasmtime exits with a Rust panic!. For me, the panic is 100% consistent and identical every time.

For me, wasmtime side:

<img width="1102" height="480" alt="Image" src="https://github.com/user-attachments/assets/e3203e8e-d0cf-499f-b3d8-8402d04e8c6e" />

lldb side:

<img width="1658" height="1218" alt="Image" src="https://github.com/user-attachments/assets/4a2644f9-b800-49f9-a332-3ed525bd8376" />

Expected Results

puzzle-invoke.wasm and puzzle.wasm should behave identically (other than -invoke's added return value). Additionally, if wasmtime puzzle.wasm works (it does), then wasmtime puzzle.wasm should work equally well. Additionally, literally nothing I can do should result in wasmtime exiting with a panic; even malformed wasm (which I do not believe puzzle.wasm is) should result in a human-readable error message.

Versions and Environment
wat2wasm --version
1.0.36

wasmtime --version
wasmtime 49.0.2 (3c8a3e79a 2026-10-02)

lldb --version
lldb version 19.1.7

lsb-release -a
Description:    Debian GNU/Linux 13 (trixie)
AMD64

wat2wasm is from debian apt wabt package
wasmtime is from cargo binstall wasmtime-cli
LLDB is from wasi-sdk-34.0-x86_64-linux release tarball from github

Extra Info

Some additional oddities:

The version without a (start) section— "puzzle-invoke"— does not crash.

The difference is the (start) section, not --invoke. As in how-to-run.txt at the link, running "puzzle" with the --invoke run flag also crashes.

Wasmtime GitHub notifications bot (Oct 07 2026 at 19:10):

alexcrichton commented on issue #14609:

If you can, our general recommendation nowadays is to not use -Ddebug-info but to instead use the guest-debug feature of wasmtime. We're unlikely to fix much any more within the current -Ddebug-info area

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

mcclure edited issue #14609:

Test Case

See this directory . It contains two .wasm files and the .wast files used to build them. Both export a single "run" function; the only difference is that "puzzle-invoke", "run" returns a number (6) and "puzzle" "run" returns nothing and furthermore is marked as the (start) function.

Steps to Reproduce

In terminal 1, run wasmtime -g 1234 -O opt-level=0 puzzle.wasm .

In terminal 2, run lldb, then run
* process connect --plugin wasm connect://127.0.0.1:1234.
* break add name run
* c

Actual Results

The moment lldb runs "continue", wasmtime exits with a Rust panic!. For me, the panic is 100% consistent and identical every time.

For me, wasmtime side:

<img width="1102" height="480" alt="Image" src="https://github.com/user-attachments/assets/e3203e8e-d0cf-499f-b3d8-8402d04e8c6e" />

lldb side:

<img width="1658" height="1218" alt="Image" src="https://github.com/user-attachments/assets/4a2644f9-b800-49f9-a332-3ed525bd8376" />

Expected Results

puzzle-invoke.wasm and puzzle.wasm should behave identically (other than -invoke's added return value). Additionally, if wasmtime puzzle.wasm works (it does), then wasmtime puzzle.wasm with breakpoints should work equally well. Additionally, literally nothing I can do should result in wasmtime exiting with a panic; even malformed wasm (which I do not believe puzzle.wasm is) should result in a human-readable error message.

Versions and Environment
wat2wasm --version
1.0.36

wasmtime --version
wasmtime 49.0.2 (3c8a3e79a 2026-10-02)

lldb --version
lldb version 19.1.7

lsb-release -a
Description:    Debian GNU/Linux 13 (trixie)
AMD64

wat2wasm is from debian apt wabt package
wasmtime is from cargo binstall wasmtime-cli
LLDB is from wasi-sdk-34.0-x86_64-linux release tarball from github

Extra Info

Some additional oddities:

The version without a (start) section— "puzzle-invoke"— does not crash.

The difference is the (start) section, not --invoke. As in how-to-run.txt at the link, running "puzzle" with the --invoke run flag also crashes.

In testing, the presence or absence of -D debug-info seems to make no difference; same with -O opt-level=0. (In one single test, the working case— "puzzle-invoke"— hung infinitely instead of breaking at the breakpoint when I ran without -O opt-level 0. But I cannot reproduce this, so there may have been some confounding factor on that one run.)

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

mcclure commented on issue #14609:

@alexcrichton , thanks— I included that line because while my problems getting wasmtime -g to work persist, I have been alternating the "guest debugging" with the gdb debugging described in 3.16.2 of the manual you link, and version 3.16.2 does recommend -D debug-info. Two notes:

I tested without -D debug-info, and removing it had no impact on the outcome of any test.

While doing this testing, I realized that the reproduction steps given in the original version of this bug were incorrect. It is not enough to simply run "puzzle.wasm" in the debugger; you also have to have set a breakpoint. I have updated the issue text (and removed -D debug-info in the process).

I notice you don't mention -O opt-level=0; it's not mentioned in the "Guest debugging" section of your manual, but I assume it's still desirable for step debugging.

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

cfallin commented on issue #14609:

Thanks for filing -- I'll take a look when I get a chance.

I notice you don't mention -O opt-level=0; it's not mentioned in the "Guest debugging" section of your manual, but I assume it's still desirable for step debugging.

Conveniently, guest debugging was actually designed to work perfectly fine with any opt level! (In the implementation, we insert instrumentation to record step-by-step values in the IR before we optimize it; those side-effects remain and we get the equivalent output even after Cranelift's optimizations.)

Last updated: Oct 11 2026 at 04:10 UTC