Stream: general

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


view this post on Zulip Boris (Jan 02 2024 at 14:30):

Hi!

versions and etc

Steps to reproduce:

Build wasm wasi binary with tinygo:

tinygo

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?

view this post on Zulip 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

view this post on Zulip 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 :)

view this post on Zulip 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)

view this post on Zulip Boris (Jan 02 2024 at 17:43):

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

view this post on Zulip Boris (Jan 02 2024 at 17:45):

didn't help, same behavior :(

view this post on Zulip Boris (Jan 02 2024 at 17:46):

how much mem does the adapter require?

view this post on Zulip Pat Hickey (Jan 02 2024 at 17:47):

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

view this post on Zulip Boris (Jan 02 2024 at 17:52):

Thanks, Pat!

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

view this post on Zulip Pat Hickey (Jan 02 2024 at 17:53):

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

view this post on Zulip Pat Hickey (Jan 02 2024 at 17:53):

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

view this post on Zulip Pat Hickey (Jan 02 2024 at 17:54):

and then use that allocation for rest of the instance


Last updated: Dec 23 2024 at 13:07 UTC