Stream: wasmtime

Topic: ✔ must use call_async with async stores

Víctor García (Jan 26 2023 at 15:10):

I'm having this error:

'thread 'main' panicked at 'must use call_async with async stores', /.cargo/registry/src/github.com-1ecc6299db9ec823/wasmtime-5.0.0/src/func/typed.rs:83:9

code:

let mut config = Config::new();
let engine = Engine::new(&config.async_support(true))?;
let module = Module::from_binary(&engine, WASM)?;
let mut linker = Linker::new(&engine);

wasmtime_wasi::tokio::add_to_linker(&mut linker, |cx| cx)?;

linker.func_wrap1_async("env", "send_request", send_request)?;

let mut store = Store::new(&engine, wasi);
let instance = linker.instantiate_async(&mut store, &module).await?;
instance
    .get_typed_func::<(), ()>(&mut store, "_start")?
    .call_async(&mut store, ())
    .await?;

Any hint what I'm doing wrong?

Lann Martin (Jan 26 2023 at 15:18):

Could you include more of the backtrace? i.e. where is the panic originating in your sample code?

Alex Crichton (Jan 26 2023 at 15:19):

you'll want to enable Config::async_support I think

Alex Crichton (Jan 26 2023 at 15:19):

oh wait sorry now I see that it's enabled

Alex Crichton (Jan 26 2023 at 15:20):

sorry yes, a backtrace or more sample code is required to diagnose

Víctor García (Jan 26 2023 at 15:39):

Solved. Some functions used in send_request used get_export, and I haven't changed the call by call_async. This is one example:

let alloc_func = caller.get_export("alloc").unwrap().into_func().unwrap();
let ptr = alloc_func
    .typed::<i32, i32>(caller.as_context())
    .unwrap()
    .call_async(caller.as_context_mut(), value.len() as i32)
    .await
    .unwrap();

Notification Bot (Jan 26 2023 at 15:49):

Lann Martin has marked this topic as resolved.

Jakob Lilliemarck (Jan 31 2023 at 06:29):

I've come across a strange error, and can't find any references. Hopefully it's just me missing something fundamental.

I've got a small wasm-lib written in rust using quickjs-wasm-rs to evaluate some js in wasm:

use quickjs_wasm_rs::{Context, Value};

#[no_mangle]
pub extern "C" fn test(i: i32) {
    let context = Context::default();
    let r = context.eval_global("name", "const f = () => 1; f()");
    println!("{:?}", r);
}

I've compiled this to the wasm32-wasi target with cargo, and it works fine when I invoke it using the wasmtime-cli, like wasmtime myModule.wasm --invoke test, but when I try and embed it I get this error: Error: expected 8 imports, found 0

This is what my embedding-program looks like atm. it's almost exactly like in one of the wasmtime examples:

use anyhow::Result;
use wasmtime::*;

fn main() -> Result<()> {
    let engine = Engine::default();
    let module = Module::from_file(&engine, "target/wasm32-wasi/debug/sbox_sandbox.wasm")?;
    let mut store = Store::new(&engine, ());
    let instance = Instance::new(&mut store, &module, &[])?;
    let func = instance.get_typed_func::<i32, i32>(&mut store, "foo")?;
    let res = func.call(&mut store, 1)?;
    println!("{:?}", res);
    Ok(())
}

Why am I getting this error, and what do I need to do to make this work? And why does it work with wasmtime-cli but not while embedding?

bjorn3 (Jan 31 2023 at 06:54):

You are missing wasmtime_wasi to define all wasi functions used by your wasm module.

Jakob Lilliemarck (Jan 31 2023 at 07:04):

Hi @bjorn3 , thanks for your reply!
When I skimmed through the quickstart-guide and examples I dont think I saw anything about this - would you be able to point me towards a code example?

How does wasmtime-cli deal with it? Do you know uf its making assumptions of its own?

bjorn3 (Jan 31 2023 at 07:07):

https://github.com/bytecodealliance/wasmtime/blob/main/examples/wasi/main.rs

bjorn3 (Jan 31 2023 at 07:08):

wasmtime-cli adds wasmtime-wasi by default.

bjorn3 (Jan 31 2023 at 07:09):

The important parts are wasmtime_wasi::add_to_linker and putting WasiCtx in the Store.

Jakob Lilliemarck (Jan 31 2023 at 18:33):

(deleted)

Jakob Lilliemarck (Jan 31 2023 at 18:34):

bjorn3 said:

The important parts are wasmtime_wasi::add_to_linker and putting WasiCtx in the Store.

19:33
Great, that indeed does work, thank you!

Regarding these WasiCtxBuilder, are there any convention on settings on a module executing untrusted javascript? I want to keep policies as strict as possible, everything the untrusted code needs will be provided as arguments to the function anyway, so no need to allow any system calls.
I looked at the docs for wasmtime-wasi, but it's very sparse to say the least :D any idea what inherit_stdio and inherit_args really means in terms of permissions within the wasm-module?

Dan Gohman (Jan 31 2023 at 18:40):

"inherit" in that context means to use the host OS process' stdio and args

Jakob Lilliemarck (Jan 31 2023 at 18:45):

ah ok, so better strip that away then. Would leaving it at let wasi = WasiCtxBuilder::new().build(); make for a safe eval of untrusted code?

Dan Gohman (Jan 31 2023 at 18:47):

Yes; that'll set up the guest with a stdin/stdout/stderr that behave as if they're connected to /dev/null, and no args/env vars/preopens

Jakob Lilliemarck (Jan 31 2023 at 19:04):

Ah, just realized the typed() only support numerical types :thinking: perhaps writing stdout somehwhere could perhaps still be considered safe - or is there a better way to get the results back, as bytes perhaps..?

Dan Gohman (Jan 31 2023 at 19:40):

WasiCtx has a set_stdout function where you can give it a Box<dyn WasiFile> which can be eg. a WritePipe. There's an example of getting the bytes here.

Last updated: Dec 23 2024 at 13:07 UTC