Repository navigation
wasm32-wasip2 on non-nightly produces bad Wasm when opt-level > 1 #148715
Description
Activity
Sound like you are hitting by some UBs (e.g. using unsafe code incorrectly).
We can't do anything with a bug report like this, only speculate.
Can you share a reproducer or the code you were building? Can you provide specifics about the errors you were encountering?
I'm not personally using unsafe code, but it could be that there's something in wasmtime. Getting a reproducible out of this will be hard, but I will try something.
One of possible solution to detect a UB is using https://github.com/rust-lang/miri. Not sure if it is possible with your code.
Thanks for the tips, everyone. I am trying to create a small reproduction without much success so far.
@bjorn3 I am not getting linker errors.
My errors happen in runtime, when running the Wasm via a programmatically initialized wasmtime environment. To be 100% clear here, there are two Rust-based programs involved in this scenario. One is the Wasm (wasm32-wasip2) and the other (x86_64-unknown-linux-gnu) loads and runs that Wasm. I see the errors in the x86 program, but it doesn't seem to matter how I build it. The errors occur when wasmtime loads a specific Wasm that is built with opt-level > 1.
I didn't detail the errors when opening the issue due to the challenges of actually getting any debug information from Wasm, and that they are internal to wasmtime and might not be useful here. But for the record, the main error seems to be this:
wasm trap: cannot enter component instanceIt actually tends to repeat several time (one wrapped in another). The most external error is this:
error while executing at wasm backtraceThanks @alexcrichton, is there a suggestion for how I can test that it is indeed due to #148347? (I am not getting a linker error on my end.)
I just confirmed that the issue appears as of right now with beta, too:
rustc 1.92.0-beta.2 (0a411606e 2025-10-31) binary: rustc commit-hash: 0a411606e9cc00588c83fcddc924395fe41079ac commit-date: 2025-10-31 host: x86_64-unknown-linux-gnu release: 1.92.0-beta.2 LLVM version: 21.1.3I'll try again tomorrow and see what's up.
Looks like it's now solved in this +beta:
rustc 1.92.0-beta.3 (f3f12444a 2025-11-09) binary: rustc commit-hash: f3f12444a017add0468f683f3a10656d29438a05 commit-date: 2025-11-09 host: x86_64-unknown-linux-gnu release: 1.92.0-beta.3 LLVM version: 21.1.3I'm impressed that you folks managed to connect my description to that other issue, which on its surface looks only indirectly related, and even know when it would be fixed. :)
- Is there something I can do to help with testing this fix?
- Should we leave this issue open until the next stable release?
Confirmation is good enough for testing out here, thanks! Given that this is solved I'll go ahead and close out this issue. Thanks again for the report @tliron and testing here
Reacted by Tal Liron
This was very hard to pin-point!
The background is that I am using wasmtime with the Component Model to run components that I am creating from Rust + wit-bindgen targeting wasm32-wasip2.
I noticed something very odd. The debug builds of my Wasm worked fine, but release builds caused some very weird errors from wasmtime.
After a lot of trial-and-error I discovered that the issue only happens when going beyond opt-level 1. Essentially running
cargo buildwithCARGO_PROFILE_RELEASE_OPT_LEVEL=1solved the problem.I further discovered that this issue doesn't happen when using
cargo +nightly build, which can use the default opt-level 3 without a problem.This might be a known issue. If it's solved in nightly, that means it might find its way to the standard channel.
However, just in case this is a fluke (or other people encounter this bug and search for solutions), hopefully this issue will help track it.
Meta
rustc --version --verbose:rustc +nightly --version --verbose: