Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when Wasmtime invokes nondefault AssemblyScript function #3474

Open
itowlson opened this issue Oct 26, 2021 · 4 comments
Open

Crash when Wasmtime invokes nondefault AssemblyScript function #3474

itowlson opened this issue Oct 26, 2021 · 4 comments

Comments

@itowlson
Copy link
Contributor

I originally raised this at AssemblyScript (AssemblyScript/assemblyscript#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 (deislabs/wagi#128).

There are additional details and discussion in the original AssemblyScript issue AssemblyScript/assemblyscript#2099.

@bjorn3
Copy link
Contributor

bjorn3 commented Oct 26, 2021

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.

WebAssembly/WASI#13

@esoterra
Copy link
Contributor

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

@bjorn3
Copy link
Contributor

bjorn3 commented Jan 29, 2024

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.

@esoterra
Copy link
Contributor

I see, I was mixing up

My bad, please disregard the above comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants