CryZe added the bug label to Issue #9130.
CryZe opened issue #9130:
Test Case
furious_fish_auto_splitter.zip
Steps to Reproduce
let engine = wasmtime::Engine::new(&wasmtime::Config::new()).unwrap(); let module = wasmtime::Module::new( &engine, include_bytes!("furious_fish_auto_splitter.wasm"), ) .unwrap();
wasmtime = { version = "23.0.2", default-features = false, features = ["cranelift", "runtime"] }
Expected Results
I'm expecting the wasm module to be parsed.
Actual Results
thread 'main' panicked at src/main.rs:18:6: called `Result::unwrap()` on an `Err` value: WebAssembly translation error Caused by: Invalid input WebAssembly code at offset 44300: zero byte expected
Versions and Environment
Wasmtime version or commit: 23.0.2
Operating system: Windows
Architecture: x86_64
Extra Info
I did by now debug this issue far enough and it turns out that the
gc
feature needs to be active, for the module to be parsed correctly.This to me seems surprising and wasn't ever needed for a wasm module that got compiled by Rust, which does not make use of any GC related feature. I'm guessing vtable pointers use function references, and the parsing infrastructure for those accidentally got gated with the GC proposal because of the "typed function references" proposal. If this is fully intended, this can be closed right away.
CryZe edited issue #9130:
Test Case
furious_fish_auto_splitter.zip
Steps to Reproduce
let engine = wasmtime::Engine::new(&wasmtime::Config::new()).unwrap(); let module = wasmtime::Module::new( &engine, include_bytes!("furious_fish_auto_splitter.wasm"), ) .unwrap();
wasmtime = { version = "23.0.2", default-features = false, features = ["cranelift", "runtime"] }
Expected Results
I'm expecting the wasm module to be parsed.
Actual Results
thread 'main' panicked at src/main.rs:18:6: called `Result::unwrap()` on an `Err` value: WebAssembly translation error Caused by: Invalid input WebAssembly code at offset 44300: zero byte expected
Versions and Environment
Wasmtime version or commit: 23.0.2
Operating system: Windows
Architecture: x86_64
Extra Info
I did by now debug this issue far enough and it turns out that the
gc
feature needs to be active for the module to be parsed correctly.This to me seems surprising and wasn't ever needed for a wasm module that got compiled by Rust, which does not make use of any GC related feature. I'm guessing vtable pointers use function references, and the parsing infrastructure for those accidentally got gated with the GC proposal because of the "typed function references" proposal. If this is fully intended, this can be closed right away.
CryZe edited issue #9130:
Test Case
furious_fish_auto_splitter.zip
Steps to Reproduce
let engine = wasmtime::Engine::new(&wasmtime::Config::new()).unwrap(); let module = wasmtime::Module::new( &engine, include_bytes!("furious_fish_auto_splitter.wasm"), ) .unwrap();
wasmtime = { version = "23.0.2", default-features = false, features = ["cranelift", "runtime"] }
Expected Results
I'm expecting the wasm module to be parsed.
Actual Results
thread 'main' panicked at src/main.rs:18:6: called `Result::unwrap()` on an `Err` value: WebAssembly translation error Caused by: Invalid input WebAssembly code at offset 44300: zero byte expected
Versions and Environment
Wasmtime version or commit: 23.0.2
Operating system: Windows
Architecture: x86_64
Extra Info
I did by now debug this issue far enough and it turns out that the
gc
feature needs to be active for the module to be parsed correctly.This to me seems surprising and wasn't ever needed for a wasm module that got compiled by Rust, which does not make use of any GC related feature. I'm guessing vtables make use of function references, and the parsing infrastructure for those accidentally got gated with the GC proposal because of the "typed function references" proposal. If this is fully intended, this can be closed right away.
alexcrichton commented on issue #9130:
Ah yes as you've discovered this is due to the fact that the way you're depending on the
wasmtime
crate disables thegc
feature. That in turn auto-disables thereference-types
WebAssembly proposal which is what's needed here. The module itself isn't using GC or anything like that, but it has:0xad06 | 11 80 80 80 | call_indirect type_index:0 table_index:0 | 80 00 80 80 | 80 80 00
that encoding of
call_indirect
was not valid before thereference_types
proposal, notably the overlong encoding oftable_index: 0
as80 80 80 80 00
. With thereference-types
feature disabled the instruction cannot be parsed. Withreference-types
enabled, which enabling thegc
crate feature does automatically, then the module can be parsed.
CryZe closed issue #9130:
Test Case
furious_fish_auto_splitter.zip
Steps to Reproduce
let engine = wasmtime::Engine::new(&wasmtime::Config::new()).unwrap(); let module = wasmtime::Module::new( &engine, include_bytes!("furious_fish_auto_splitter.wasm"), ) .unwrap();
wasmtime = { version = "23.0.2", default-features = false, features = ["cranelift", "runtime"] }
Expected Results
I'm expecting the wasm module to be parsed.
Actual Results
thread 'main' panicked at src/main.rs:18:6: called `Result::unwrap()` on an `Err` value: WebAssembly translation error Caused by: Invalid input WebAssembly code at offset 44300: zero byte expected
Versions and Environment
Wasmtime version or commit: 23.0.2
Operating system: Windows
Architecture: x86_64
Extra Info
I did by now debug this issue far enough and it turns out that the
gc
feature needs to be active for the module to be parsed correctly.This to me seems surprising and wasn't ever needed for a wasm module that got compiled by Rust, which does not make use of any GC related feature. I'm guessing vtables make use of function references, and the parsing infrastructure for those accidentally got gated with the GC proposal because of the "typed function references" proposal. If this is fully intended, this can be closed right away.
CryZe commented on issue #9130:
Ah and that's because I use the nightly Rust compiler with the update to LLVM 19, which enables
reference-types
by default. Though I was not aware that it actually had some sort of impact. Good to know. Thank you for looking into it.
alexcrichton commented on issue #9130:
In case anyone comes across this in the future, Wasmtime 25 will include https://github.com/bytecodealliance/wasmtime/pull/9162 which means that this issue should no longer come up or be relevant. Disabling the
gc
feature of Wasmtime will preserve the ability of Wasmtime to read LLVM 19+ modules, and only use ofexternref
in wasm modules (and other gc types) will be gated when the Wasmtime compile-time-feature ofgc
is disabled.
brooksmtownsend commented on issue #9130:
@alexcrichton perfect timing! I just came across this issue this AM looking to enable running wasm32-wasip2 components built via
cargo +nightly
and I was looking to enable thegc
feature to enable it https://github.com/wasmCloud/wasmCloud/pull/2848.So in wasmtime 25 I won't need the
gc
feature?
alexcrichton commented on issue #9130:
Correct!
Last updated: Dec 23 2024 at 12:05 UTC