wasmtime / issue #9130 WebAssembly translation error rela... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #9130 WebAssembly translation error rela...

Wasmtime GitHub notifications bot (Aug 14 2024 at 17:13):

CryZe added the bug label to Issue #9130.

Wasmtime GitHub notifications bot (Aug 14 2024 at 17:13):

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.

Wasmtime GitHub notifications bot (Aug 14 2024 at 17:14):

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.

Wasmtime GitHub notifications bot (Aug 14 2024 at 17:15):

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.

Wasmtime GitHub notifications bot (Aug 14 2024 at 18:15):

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 the gc feature. That in turn auto-disables the reference-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 the reference_types proposal, notably the overlong encoding of table_index: 0 as 80 80 80 80 00. With the reference-types feature disabled the instruction cannot be parsed. With reference-types enabled, which enabling the gc crate feature does automatically, then the module can be parsed.

Wasmtime GitHub notifications bot (Aug 14 2024 at 18:23):

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.

Wasmtime GitHub notifications bot (Aug 14 2024 at 18:23):

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.

Wasmtime GitHub notifications bot (Aug 23 2024 at 15:26):

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 of externref in wasm modules (and other gc types) will be gated when the Wasmtime compile-time-feature of gc is disabled.

Wasmtime GitHub notifications bot (Aug 23 2024 at 15:35):

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 the gc feature to enable it https://github.com/wasmCloud/wasmCloud/pull/2848.

So in wasmtime 25 I won't need the gc feature?

Wasmtime GitHub notifications bot (Aug 23 2024 at 15:43):

alexcrichton commented on issue #9130:

Correct!

Last updated: Nov 22 2024 at 16:03 UTC