Error assertion left == right failed on Wasm module init in Rust-embedded Wasmtime
#9714
Comments
epsylonix
added
the
bug
alexcrichton
added
the
wasm-proposal:gc
|
I've also encountered a similar issue in the standalone mode with when added any non-trivial code. For example, using Kotlin's Execution results in this error: I tested it with WasmEdge and it this works there so I assume this is a Wasmtime issue, not Kotlin. |
|
Thanks for filing an issue! Can you attach the |
|
Thank you for looking into this! Here are two wasm files for both issues I've mentined.
|
|
I've used (module
(type (;0;) (func))
(rec
(type (;1;) (struct))
(type (;2;) (struct))
(type (;3;) (struct))
(type (;4;) (struct))
(type (;5;) (struct))
(type (;6;) (struct))
(type (;7;) (struct))
(type (;8;) (struct))
(type (;9;) (struct))
(type (;10;) (struct))
(type (;11;) (struct))
(type (;12;) (struct))
(type (;13;) (array (mut (ref 2))))
(type (;14;) (array i16))
(type (;15;) (struct (field (ref 2)) (field (ref 1))))
)
(global (;0;) (ref 15) struct.new_default 2 struct.new_default 1 struct.new 15)
) |
|
Further reduced by hand: (module
(rec
(type $b (struct))
(type $a (struct (field (ref $b))))
)
(global (;0;) (ref $a)
struct.new_default $b
struct.new $a
)
) |
We were incorrectly checking whether they were in the same rec group (i.e. whether the two `RegisteredType`s had the same `RecGroupEntry`) rather than whether they were actually the same type or not, even if they were in the same rec group. This fixes one of two issues reported in bytecodealliance#9714
|
Fix for the |
We were incorrectly checking whether they were in the same rec group (i.e. whether the two `RegisteredType`s had the same `RecGroupEntry`) rather than whether they were actually the same type or not, even if they were in the same rec group. This fixes one of two issues reported in #9714
It is possible for two `WasmSubType`s to be equal to each other, as far as `derive(PartialEq)` is concerned, but still different from each other if they are in different rec groups or even if they are at different indices within the same rec group. The assertion mistakenly did not permit either of these, however. Fixes bytecodealliance#9714
It is possible for two `WasmSubType`s to be equal to each other, as far as `derive(PartialEq)` is concerned, but still different from each other if they are in different rec groups or even if they are at different indices within the same rec group. The assertion mistakenly did not permit either of these, however. Fixes bytecodealliance#9714
…e usage in ExternType::from_wasmtime (#10223) * Fix assertion in `PartialEq` for `RegisteredType` again It is possible for two `WasmSubType`s to be equal to each other, as far as `derive(PartialEq)` is concerned, but still different from each other if they are in different rec groups or even if they are at different indices within the same rec group. The assertion mistakenly did not permit either of these, however. Fixes #9714 * Canonicalize all types for runtime usage when creating `wasmtime::{Module,Component}`s Rather than canonicalizing them on demand in functions like `{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it in one place, up front, so that it is very unlikely we miss anything. Doing this involves changing some things from `ModuleInternedTypeIndex`es to `EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch of uses of those things need to unwrap the appropriate kind of type index at usage sites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtime uses usage will unwrap `VMSharedTypeIndex`es). And it additionally required implementing the `TypeTrace` trait for a handful of things to unlock the provided `canonicalize_for_runtime_usage` trait method for those things. All this machinery is required to avoid an assertion failure in the regression test introduced in the previous commit, which was triggered because we were failing to canonicalize type indices inside `ExternType`s for runtime usage on some code paths. We shouldn't have to play that kind of whack-a-mole in the future, thanks to this new approach. * Fix a warning in no-default-features builds * Fix another warning in weird cfg builds
Test Case
I'm trying to run a Kotlin-produced Wasm module in Rust-embedded Wasmtime. Kotlin requires support for the Wasm GC proposal, which Wasmtime officially has since version 27.0.0. Unfortunately, when initializing the Kotlin-generated Wasm module, a Wasmtime assertion error occurs, seemingly related to the Wasm GC code.
I initially assumed some incompatibility between Wasmtime and Kotlin-produced Wasm but the same file can be executed successfully in the standalone mode with
wasmtime -W function-references,gc.The minimal Kotlin guest code that reproduces this issue looks like this:
And this is the corresponding host code:
This fails at
linker.instantiatecall with an error:Versions and Environment
Wasmtime version or commit: 27.0.0
Operating system: macOS
Architecture: arm64
The text was updated successfully, but these errors were encountered: