Stream: git-wasmtime

Topic: wasmtime / issue #3661 Instance panics if too many import...

Wasmtime GitHub notifications bot (Jan 07 2022 at 12:58):

andyherbert opened issue #3661:

Feature

Currently wasmtime panics if too many imports are provided to an instance, however in a warm module imports may be optimised away (for example with AssemblyScript), if calls to these imports are unreachable or not present.

Benefit

My particular use case is that I am embedding wasmtime in a Rust application and providing hooks to the host application, in the very likely event that someone writing the wasm module decides not to use one or more of the hooks then my application fails as I would be providing too many imports.

Implementation

Alternatives

Wasmtime GitHub notifications bot (Jan 07 2022 at 15:34):

alexcrichton commented on issue #3661:

Can you provide example code and/or an example module that triggers this? Excessive imports can theoretically reach a validation error if there's too many but that shouldn't result in a panic, that's definitely a bug in Wasmtime.

Wasmtime GitHub notifications bot (Jan 07 2022 at 16:21):

andyherbert commented on issue #3661:

The problem isn't because of an excessive amount of imports, it's due to the import being optimised away by (in this case) binaryen.

declare namespace env {
    export function foo(): void
    export function bar(): void
}

env.foo();
// env.bar();

    let foo = Func::wrap(&mut store, |_: Caller<'_, u32>| {});
    let bar = Func::wrap(&mut store, |_: Caller<'_, u32>| {});
    let instance = Instance::new(&mut store, &module, &[foo.into(), bar.into()]).expect("instance");

thread 'main' panicked at 'instance: expected 1 imports, found 2'

Wasmtime GitHub notifications bot (Jan 07 2022 at 16:54):

alexcrichton commented on issue #3661:

Ah ok, thanks for the clarification. This is not a panic in Wasmtime but rather a panic in your code (the expect). This is also due to the low-level nature of Instance::new. For your use case I'd recommend using Linker to instantiate modules which does name-based resolution which is probably what you want.

Wasmtime GitHub notifications bot (Jan 07 2022 at 16:54):

alexcrichton closed issue #3661:

Feature

Currently wasmtime panics if too many imports are provided to an instance, however in a warm module imports may be optimised away (for example with AssemblyScript), if calls to these imports are unreachable or not present.

Benefit

My particular use case is that I am embedding wasmtime in a Rust application and providing hooks to the host application, in the very likely event that someone writing the wasm module decides not to use one or more of the hooks then my application fails as I would be providing too many imports.

Implementation

Alternatives

Wasmtime GitHub notifications bot (Jan 07 2022 at 16:58):

andyherbert commented on issue #3661:

Ah okay, I must have missed the Linker, many thanks.

Last updated: Nov 22 2024 at 17:03 UTC