Stream: git-wasmtime

Topic: wasmtime / issue #3474 Crash when Wasmtime invokes nondef...

Wasmtime GitHub notifications bot (Oct 26 2021 at 00:27):

itowlson opened issue #3474:

I originally raised this at AssemblyScript (https://github.com/AssemblyScript/assemblyscript/issues/2099) but they appear to view it as an issue with Wasm runtimes; they have raised a Wasmer bug but my use case is Wasmtime.

---

Consider the following AssemblyScript program:

import "wasi";

export function foo(): void {
  console.log("foo");
  console.log(Math.random().toString());
}

console.log("start");

Compile this using

asc test.ts --explicitStart --debug

Now run wasmtime run --invoke foo ./build/untouched.wasm

It crashes with:

Caused by:
    0: failed to invoke `foo`
    1: exit with invalid exit status outside of [0..126)
       wasm backtrace:
           0:  0x5a9 - <unknown>!~lib/wasi/index/abort
           1: 0x2c4a - <unknown>!~lib/rt/itcms/visitRoots
           2: 0x2e73 - <unknown>!~lib/rt/itcms/step
           3: 0x2fb2 - <unknown>!~lib/rt/itcms/interrupt
           4: 0x31ea - <unknown>!~lib/rt/itcms/__new
           5: 0x3441 - <unknown>!~lib/util/number/dtoa
           6: 0x322c - <unknown>!~lib/number/F64#toString
           7: 0x337b - <unknown>!assembly/index/foo```

The crash occurs within the AssemblyScript garbage collector while trying to allocate a string.

I believe the reason AssemblyScript considers this a runtime bug is that they set up the GC in the implicit _start function. Calling wasmtime run --invoke foo bypasses _start and therefore the GC is not set up when it needs to do the allocation.

This also occurs when invoking the function via the Wasmtime Rust crate hosted in my own program (https://github.com/deislabs/wagi/issues/128).

There are additional details and discussion in the original AssemblyScript issue https://github.com/AssemblyScript/assemblyscript/issues/2099.

Wasmtime GitHub notifications bot (Oct 26 2021 at 09:04):

bjorn3 commented on issue #3474:

There are two kinds of wasi programs:

• commands: These are like executables and need _start invoked one time. Once it returns you are no longer allowed to call into it ever again.
• reactors: These are like libraries and need _initialize invoked one time. Once it returns you are allowed to call any exported function as many times as you want. (subject to restrictions defined by the specific reactor you are running)

If assemblyscript wants to allow invoking functions other than _start, it will need to create wasi reactors AFAIK and thus provide an _initialize function instead of a _start function. It is not valid to provide both.

https://github.com/WebAssembly/WASI/issues/13

Wasmtime GitHub notifications bot (Jan 29 2024 at 16:27):

esoterra commented on issue #3474:

@itowlson are you saying that we aren't calling the module _start function during module initialization as required by spec?

Wasmtime GitHub notifications bot (Jan 29 2024 at 17:07):

bjorn3 commented on issue #3474:

WASI's _start and the wasm start function are entirely separate. The wasm start function is always called during module instantiation, before you get access to the wasm module instance. Because of this, it is impossible for functions called by the start function to get access to any of the exports of the wasm module that is running the start function. This includes the memory export that WASI needs for pointer accesses. For this reason WASI uses a separate _start (for commands) or _initialize (for reactors) function that runs after the wasm module has been instantiated.

Wasmtime GitHub notifications bot (Jan 29 2024 at 18:11):

esoterra commented on issue #3474:

I see, I was mixing up

• Module start
• Component start, and
• Preview 1 _start

My bad, please disregard the above comment.

Last updated: Dec 23 2024 at 12:05 UTC