Repository navigation
Segfault with exceptions + single-pass regalloc #11850
Description
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
Activity
alexcrichton commentedon Oct 15, 2025
Another example is:
When
-Oopt-level=0is removed this yields:Disable single-pass regalloc in fuzzing and add docs
Disable single-pass regalloc in fuzzing and add docs (#11864)
Disable single-pass regalloc in fuzzing and add docs (bytecodeallianc…
d-sonuga commentedon Nov 5, 2025
Hey @alexcrichton, how do I run the fuzzer on macOS. I tried
cargo +nightly fuzz run wast_testsbut I get this OCaml-related build error:failed to run custom build command forwasm-spec-interpreterandFailed to build the OCaml library using 'make'.`Is there any OCaml-specific setup I need to do first?
alexcrichton commentedon Nov 5, 2025
That command's the one yeah. To disable the need for ocaml you can pass
--no-default-featuresand I would also recommend passing--sanitizer noneas it speeds up fuzzing by a fair bit too (and compilation!)d-sonuga commentedon Nov 5, 2025
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.
alexcrichton commentedon Nov 5, 2025
Could you paste an example of what the failure looks like? For
wast_testsI'm not aware of any failures like that. FordifferentialI know of one esoteric failure (possibly), but I'm not sure if you're running into thatd-sonuga commentedon Nov 5, 2025
Here's one:
alexcrichton commentedon Nov 5, 2025
Hm ok that I'm not sure about. I'll run locally and see if I can reproduce as well.
Using
RUST_LOG=wasmtime_fuzzingit 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 :(Disable mach ports during fuzzing
Disable mach ports during fuzzing
1 remaining item
Disable mach ports during fuzzing (#11990)
kayabaNerve commentedon Nov 9, 2025
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:
unsafecode here, so it is a problem within a dependencyThe 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).
alexcrichton commentedon Nov 9, 2025
@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.
kayabaNerve commentedon Nov 9, 2025
Will do if I identify it as within
wasmtimeand not one of a thousand other crates 😅 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.alexcrichton commentedon Nov 9, 2025
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
cfallin commentedon Nov 9, 2025
@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)
kayabaNerve commentedon Nov 10, 2025
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 thewasmtimeupgrade 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.
alexcrichton commentedon Nov 10, 2025
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...
Handle case where livein is defined on a branch instruction (#246)
cfallin commentedon Nov 13, 2025
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.
Upgrade regalloc2 to 0.13.3.
Upgrade regalloc2 to 0.13.3. (#12027)