wasm32-wasip2 on non-nightly produces bad Wasm when opt-level > 1

[tliron]

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 build with CARGO_PROFILE_RELEASE_OPT_LEVEL=1 solved 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 1.91.0 (f8297e351 2025-10-28)
binary: rustc
commit-hash: f8297e351a40c1439a467bbbb6879088047f50b3
commit-date: 2025-10-28
host: x86_64-unknown-linux-gnu
release: 1.91.0
LLVM version: 21.1.2

rustc +nightly --version --verbose:

rustc 1.93.0-nightly (843f8ce2e 2025-11-07)
binary: rustc
commit-hash: 843f8ce2ebc01d35a30484eadc8a84cdc6130844
commit-date: 2025-11-07
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.3

[ultimaweapon]

Sound like you are hitting by some UBs (e.g. using unsafe code incorrectly).

[saethlin]

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?

[tliron]

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.

[ultimaweapon]

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.

[bjorn3]

What kind of errors? If it is #148347 that will be fixed in the upcoming 1.91.1 patch release.

[tliron]

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 instance

It actually tends to repeat several time (one wrapped in another). The most external error is this:

error while executing at wasm backtrace

[bjorn3]

#148347 can also cause a miscompilation without linker error.

[alexcrichton]

If the component here works on nightly this is almost surely another version of #148347 which was fixed in #148363 on nightly. As bjorn3 mentioned that'll get backported to beta/stable soon.

[tliron]

Thanks @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.)

[bjorn3]

You could check if it is broken on beta today and fixed tomorrow (a couple of hours past midnight utc time) after updating beta. #148591 which backports #148363 to beta landed earlier today.

[tliron]

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.3

I'll try again tomorrow and see what's up.