Stream: general

Topic: wasm component model + tinygo + wasi leads to assertion fail

Boris (Jan 02 2024 at 14:30):

Hi!

Steps to reproduce:

Build wasm wasi binary with tinygo:

wg.Add(10)

for i := 0; i < 10; i++ {
    go func(wg *sync.WaitGroup, id int) {
        defer wg.Done()

        fmt.Printf("[%d] hello goroutine!\n", id)
    }(&wg, i)
}

wg.Wait()

Build component from wasm core module:

wasm-tools component new tinygo.wasm --adapt wasi_snapshot_preview1.command.wasm -o tinygo.component.wasm

Run:

wasmtime -D logging=y --wasm component-model tinygo.component.wasm

Got error:

unreachable executed at adapter line 2552: assertion failed

Error: failed to run main module `tinygo.component.wasm`

Caused by:
    0: failed to invoke `run` function
    1: error while executing at wasm backtrace:
           0: 0x2a398 - wit-component:adapter:wasi_snapshot_preview1!fd_write
           1: 0x2e83f - wit-component:shim!adapt-wasi_snapshot_preview1-fd_write
           2: 0x147f6 - <unknown>!(os.unixFileHandle).Write
           3: 0x7ee9 - <unknown>!(*os.File).Write
           4: 0x7cd5 - <unknown>!interface:{Write:func:{slice:basic:uint8}{basic:int,named:error}}.Write$invoke
           5: 0xa809 - <unknown>!main.main$2$gowrapper
           6: 0x8e64 - <unknown>!_start
           7: 0x27598 - wit-component:adapter:wasi_snapshot_preview1!wasi:cli/run@0.2.0-rc-2023-12-05#run
    2: wasm trap: wasm `unreachable` instruction executed

Running original core wasm binary works just fine:

wasmtime -D logging=y build/tinygo.wasm

[0] hello goroutine!
[1] hello goroutine!
[2] hello goroutine!
[3] hello goroutine!
[4] hello goroutine!
[5] hello goroutine!
[6] hello goroutine!
[7] hello goroutine!
[8] hello goroutine!
[9] hello goroutine!

I have looked at the adapter source, the assertion that failed looks like this:

impl State {
    fn with(f: impl FnOnce(&State) -> Result<(), Errno>) -> Errno {
        let state_ref = State::ptr();
        assert_eq!(state_ref.magic1, MAGIC); // HERE crates/wasi-preview1-component-adapter/src/lib.rs:2552
        assert_eq!(state_ref.magic2, MAGIC);
        let ret = f(state_ref);
        match ret {
            Ok(()) => ERRNO_SUCCESS,
            Err(err) => err,
        }
    }
}

Where I should start debugging?

Alex Crichton (Jan 02 2024 at 17:10):

If that assertion is tripping then that means that some memory corruption has happened in the guest somewhere. I'm not sure how best to debug that but it may mean that tinygo's allocator doesn't play well with what the adapter is doing to allocate its own state and/or its stack

Boris (Jan 02 2024 at 17:24):

Thanks, Alex!

doing to allocate its own state and/or its stack
sounds like I can try to play with the base address (or something similar) of tinygo :)

Alex Crichton (Jan 02 2024 at 17:34):

There's a few ways that the adapter tries to allocate things, I think it tries to use cabi_realloc by default if it's present, but it's possible to configure wasm-tools component new to always use memory.grow I believe (I also forget if that was a wish-to-be-implemented or has-been-implemented thing)

Boris (Jan 02 2024 at 17:43):

yes, it has-been-implemented thing )
I will try --realloc-via-memory-grow, thanks!

Boris (Jan 02 2024 at 17:45):

didn't help, same behavior :(

Boris (Jan 02 2024 at 17:46):

how much mem does the adapter require?

Pat Hickey (Jan 02 2024 at 17:47):

allegedly it will only consume 1 wasm page (64k)

Boris (Jan 02 2024 at 17:52):

Thanks, Pat!

So for example, if I somehow reserve this 1 page, everything should work fine?

Pat Hickey (Jan 02 2024 at 17:53):

https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/src/lib.rs#L2591

Pat Hickey (Jan 02 2024 at 17:53):

the adapter will use a function exported as "cabi_realloc" from the adaptee module

Pat Hickey (Jan 02 2024 at 17:54):

and then use that allocation for rest of the instance

Last updated: Nov 22 2024 at 17:03 UTC