Stream: git-wasmtime

Topic: wasmtime / issue #11850 Segfault with exceptions + single...

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 14:33):

alexcrichton opened issue #11850:

Using Wasmtime 37.0.2 I get:

$ wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast

thread 'main' panicked at /home/runner/work/wasmtime/wasmtime/crates/unwinder/src/exception_table.rs:168:25:
Wasmtime exception unwind info only supports dynamic contexts on the stack
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: IOT instruction (core dumped)  wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

using main I get: 

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast
...
zsh: segmentation fault (core dumped)  cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

My guess is that this is related to the single-pass register allocator, so cc @d-sonuga

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 14:33):

alexcrichton added the fuzz-bug label to Issue #11850.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 14:33):

alexcrichton added the cranelift:area:regalloc label to Issue #11850.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 14:33):

alexcrichton added the wasm-proposal:exceptions label to Issue #11850.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 15 2025 at 16:01):

alexcrichton commented on issue #11850:

Another example is:

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oopt-level=0 -Oregalloc-algorithm=single-pass -Wexceptions,function-references ./tests/spec_testsuite/proposals/wasm-3.0/try_table.wast
...
zsh: segmentation fault (core dumped)  cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

When -Oopt-level=0 is removed this yields:

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions,function-references ./tests/spec_testsuite/proposals/wasm-3.0/try_table.wast
...
Error: failed to run script file './tests/spec_testsuite/proposals/wasm-3.0/try_table.wast'

Caused by:
    0: failed directive on ./tests/spec_testsuite/proposals/wasm-3.0/try_table.wast:302
    1: result 0 didn't match
    2: expected                  5 / 0x0000000000000005
       actual                    0 / 0x0000000000000000

view this post on Zulip Wasmtime GitHub notifications bot (Nov 05 2025 at 18:11):

d-sonuga commented on issue #11850:

Hey @alexcrichton, how do I run the fuzzer on macOS. I tried cargo +nightly fuzz run wast_tests but I get this OCaml-related build error: failed to run custom build command for wasm-spec-interpreter and Failed to build the OCaml library using 'make'.`
Is there any OCaml-specific setup I need to do first?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 05 2025 at 18:36):

alexcrichton commented on issue #11850:

That command's the one yeah. To disable the need for ocaml you can pass --no-default-features and I would also recommend passing --sanitizer none as it speeds up fuzzing by a fair bit too (and compilation!)

view this post on Zulip Wasmtime GitHub notifications bot (Nov 05 2025 at 20:28):

d-sonuga commented on issue #11850:

Thanks!
But there's another issue: after running for a few seconds, it fails, but when I try to rerun the failed input, it passes, and I don't think this has anything to do with the allocator.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 05 2025 at 20:28):

d-sonuga edited a comment on issue #11850:

Thanks!
But there's another issue: after running for a few seconds, it fails, but when I try to rerun the failed input, it passes, and I don't think this particular failure has anything to do with the allocator.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 05 2025 at 20:32):

alexcrichton commented on issue #11850:

Could you paste an example of what the failure looks like? For wast_tests I'm not aware of any failures like that. For differential I know of one esoteric failure (possibly), but I'm not sure if you're running into that

view this post on Zulip Wasmtime GitHub notifications bot (Nov 05 2025 at 20:45):

d-sonuga commented on issue #11850:

Here's one:

==30721== ERROR: libFuzzer: deadly signal
NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 2 CrossOver-CopyPart-; base unit: 5fca8986ed075873381dbb53bd351e47403b848b
0x0,0xff,0xff,0x1,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x3e,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x80,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x81,0x81,0x81,0x81,0x81,0x81,0x81,0xff,0x81,0x81,0x81,0x81,0xff,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0xd7,0xd7,0xd7,0xd7,0xd7,0xd7,0xd7,0xd7,0x0,0xff,0x0,0x0,0x0,0x0,0x0,0x26,0x0,0x0,0x58,0x58,0x58,0x58,0x58,0x58,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x58,0x58,0x58,0x5a,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x0,0x0,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x58,0x5d,0x58,0x58,0x0,0x0,
\000\377\377\001\000\000\000\000\000\000\000\000\000XXXXXXXX>\000\000\000\000\000\000\000\200XXXXXXXXXX\201\201\201\201\201\201\201\377\201\201\201\201\377XXXXXXXXXXXXXXXXXX\327\327\327\327\327\327\327\327\000\377\000\000\000\000\000&\000\000XXXXXX\000\000\000\000\000\000\000\000\000XXXZXXXXXXXXXX\000\000XXXXXXXXXX]XX\000\000
artifact_prefix='/Users/d-sonuga/repos/wasmtime/fuzz/artifacts/wast_tests/'; Test unit written to /Users/d-sonuga/repos/wasmtime/fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f
Base64: AP//AQAAAAAAAAAAAFhYWFhYWFhYPgAAAAAAAACAWFhYWFhYWFhYWIGBgYGBgYH/gYGBgf9YWFhYWFhYWFhYWFhYWFhYWFjX19fX19fX1wD/AAAAAAAmAABYWFhYWFgAAAAAAAAAAABYWFhaWFhYWFhYWFhYWAAAWFhYWFhYWFhYWF1YWAAA

────────────────────────────────────────────────────────────────────────────────

Failing input:

    fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f

Output of `std::fmt::Debug`:

    [0, 255, 255, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 88, 88, 88, 88, 88, 88, 88, 88, 62, 0, 0, 0, 0, 0, 0, 0, 128, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 129, 129, 129, 129, 129, 129, 129, 255, 129, 129, 129, 129, 255, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 215, 215, 215, 215, 215, 215, 215, 215, 0, 255, 0, 0, 0, 0, 0, 38, 0, 0, 88, 88, 88, 88, 88, 88, 0, 0, 0, 0, 0, 0, 0, 0, 0, 88, 88, 88, 90, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 0, 0, 88, 88, 88, 88, 88, 88, 88, 88, 88, 88, 93, 88, 88, 0, 0]

Reproduce with:

    cargo fuzz run --no-default-features --sanitizer=none wast_tests fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f

Minimize test case with:

    cargo fuzz tmin --no-default-features --sanitizer=none wast_tests fuzz/artifacts/wast_tests/crash-2571966bf9ef0f84826111ad1295349fc069e71f

────────────────────────────────────────────────────────────────────────────────

Error: Fuzz target exited with exit status: 77

view this post on Zulip Wasmtime GitHub notifications bot (Nov 05 2025 at 22:26):

alexcrichton commented on issue #11850:

Hm ok that I'm not sure about. I'll run locally and see if I can reproduce as well.

Using RUST_LOG=wasmtime_fuzzing it looks like that test is executing a threads-related test, so it might have something to do with that? Not that that's helpful alas :(

view this post on Zulip Wasmtime GitHub notifications bot (Nov 06 2025 at 16:21):

alexcrichton commented on issue #11850:

Well I can reproduce locally on macOS. Adding some debugging it looks like signals are just bypassing our handler entirely. I... don't have any idea why that's happening unfortunately. I've attempted a workaround at https://github.com/bytecodealliance/wasmtime/pull/11990 which should get fuzzing to continue better.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 09 2025 at 06:00):

kayabaNerve commented on issue #11850:

I have a segfault _somewhere_ after upgrading a large codebase from wasmtime 36 to wasmtime 38 (and a variety of other _updates_ (not upgrades) to our tree). I have yet to do any analysis, so I cannot confirm it's from wasmtime or even directly related to this issue, but:

1) wasmtime is my second largest dependency and apparently has an observed segfault in the most recent versions
2) My first largest dependency doesn't have any tracking issues for introduced segfaults
3) I don't personally have any unsafe code here, so it is a problem within a dependency
4) I've had other issues since upgrading*.

The reason I comment here is I don't set the regalloc algorithm and the default IS NOT single-pass regalloc (at least according to the documentation). That means, if my segfault is this segfault, that's a red-herring.

*I had proof-carrying code enabled. It worked with wasmtime 36, yet with wasmtime 38 (and any side-effects from the updates within semver that I performed), wasmtime started yielding unsupported instruction errors and failing to instantiate its runtime. I didn't bother analyzing and opening a proper issue due to this comment. After I disabled proof-carrying code, I now have a segfault _somewhere_.

Apologies for how messy this comment is. I do plan to do further analysis as this is now my problem to deal with. I just wanted to put my initial notes down in case it ends up helpful.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 09 2025 at 06:09):

kayabaNerve edited a comment on issue #11850:

I have a segfault _somewhere_ after upgrading a large codebase from wasmtime 36 to wasmtime 38 (and a variety of other _updates_ (not upgrades) to our tree). I have yet to do any analysis, so I cannot confirm it's from wasmtime or even directly related to this issue, but:

1) wasmtime is my second largest dependency and apparently has an observed segfault in the most recent versions
2) My first largest dependency doesn't have any tracking issues for introduced segfaults
3) I don't personally have any unsafe code here, so it is a problem within a dependency
4) I've had other issues since upgrading*.

The reason I comment here is I don't set the regalloc algorithm and the default IS NOT single-pass regalloc (at least according to the documentation). That means, if my segfault is this segfault, that's a red-herring.

*I had proof-carrying code enabled. It worked with wasmtime 36, yet with wasmtime 38 (and any side-effects from the updates within semver that I performed), wasmtime started yielding unsupported instruction errors and failing to instantiate its runtime. I didn't bother analyzing and opening a proper issue due to this comment. After I disabled proof-carrying code, I now have a segfault _somewhere_.

Apologies for how messy this comment is. I do plan to do further analysis as this is now my problem to deal with. I just wanted to put my initial notes down in case it ends up helpful (for anyone investigating this or for anyone with the same issues or for myself).

view this post on Zulip Wasmtime GitHub notifications bot (Nov 09 2025 at 17:14):

alexcrichton commented on issue #11850:

@kayabaNerve thanks for the comment! If you're not specifically enabling an alternative regalloc algorithm then it's not this issue and is possibly something else. This issue is for a non-default setting of Wasmtime.

That being said if you think that the segfault is in Wasmtime that would likely make the issue a security bug. If you'd like you can open a draft security issue on Wasmtime and we can discuss further there.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 09 2025 at 17:33):

kayabaNerve commented on issue #11850:

Will do if I identify it as within wasmtime and not one of a thousand other crates :sweat_smile: Apologies for the noise here. I didn't know if it was definitely tracked to single-pass regalloc due to "My guess is that this is related to the single-pass register allocator", hence why I wanted to chime in.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 09 2025 at 17:45):

alexcrichton commented on issue #11850:

No worries! If you're comfortable sharing a gdb stack trace or similar (and are able to capture it) in a private issue we can try to help poke at it a bit

view this post on Zulip Wasmtime GitHub notifications bot (Nov 09 2025 at 21:37):

cfallin commented on issue #11850:

@kayabaNerve I don't see it explicitly stated either way in your comments above, so it might help to clarify: are you enabling the single-pass register allocator in your configuration?

(This is useful not just to help us help you, but to help us get an urgency signal for ourselves too)

view this post on Zulip Wasmtime GitHub notifications bot (Nov 10 2025 at 05:53):

kayabaNerve commented on issue #11850:

Hello,

I'm incredibly sorry for all the concern and potentially violating any intended disclosure policies. I only commented here as I had an anecdote I thought may become relevant.

I did sit back down with this today and took the immediate step of reverting to wasmtime 36, for which I can confirm the segfault is still present, meaning the wasmtime upgrade is almost certainly not what's at fault and I have some other idiocy in a very large stack.

I apologize again for the noise and want to note my utmost respect for how amazingly attentive you were to a potential security issue.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 10 2025 at 15:58):

alexcrichton commented on issue #11850:

No worries! Best of luck tracking it down nonetheless, I imagine it's going to be either a fun one or a very much not fun one...

view this post on Zulip Wasmtime GitHub notifications bot (Nov 13 2025 at 19:17):

cfallin closed issue #11850:

Using Wasmtime 37.0.2 I get:

$ wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast

thread 'main' panicked at /home/runner/work/wasmtime/wasmtime/crates/unwinder/src/exception_table.rs:168:25:
Wasmtime exception unwind info only supports dynamic contexts on the stack
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: IOT instruction (core dumped)  wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

using main I get: 

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast
...
zsh: segmentation fault (core dumped)  cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

My guess is that this is related to the single-pass register allocator, so cc @d-sonuga

view this post on Zulip Wasmtime GitHub notifications bot (Nov 13 2025 at 19:20):

cfallin reopened issue #11850:

Using Wasmtime 37.0.2 I get:

$ wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast

thread 'main' panicked at /home/runner/work/wasmtime/wasmtime/crates/unwinder/src/exception_table.rs:168:25:
Wasmtime exception unwind info only supports dynamic contexts on the stack
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: IOT instruction (core dumped)  wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

using main I get: 

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast
...
zsh: segmentation fault (core dumped)  cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

My guess is that this is related to the single-pass register allocator, so cc @d-sonuga

view this post on Zulip Wasmtime GitHub notifications bot (Nov 13 2025 at 19:20):

cfallin commented on issue #11850:

GitHub parsed the commit message in regalloc2#246, but this is still open until we release (regalloc2#248) and upgrade to that release here.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 13 2025 at 19:21):

cfallin edited a comment on issue #11850:

GitHub parsed the commit message in bytecodealliance/regalloc2#246, but this is still open until we release (bytecodealliance/regalloc2#248) and upgrade to that release here.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 13 2025 at 20:54):

cfallin closed issue #11850:

Using Wasmtime 37.0.2 I get:

$ wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast

thread 'main' panicked at /home/runner/work/wasmtime/wasmtime/crates/unwinder/src/exception_table.rs:168:25:
Wasmtime exception unwind info only supports dynamic contexts on the stack
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: IOT instruction (core dumped)  wasmtime wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

using main I get: 

$ cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes -Oregalloc-algorithm=single-pass -Wexceptions=y tests/spec_testsuite/proposals/wasm-3.0/throw.wast
...
zsh: segmentation fault (core dumped)  cargo run wast -Cinlining=y -Ccranelift-wasmtime_inlining_intra_module=yes

My guess is that this is related to the single-pass register allocator, so cc @d-sonuga

Last updated: Dec 06 2025 at 07:03 UTC