Closed milesj closed 3 weeks ago
Thanks for the report! If you're able to reproduce locally can you attach gdb
and capture a backtrace of the thread at the time of the panic?
That backtrace should be able to go through wasm code and see everything and that's the main culprit to look at there. My hunch as to what's going on is that you're executing WebAssembly code on a Tokio event loop and that's what's causing the panic. This is just a hunch though so a stack trace would be able to help diagnose this. If this is the case then the best fix would likely be to offload the execution of WebAssembly to a worker thread not on the Tokio event loop
@alexcrichton - thanks for the suggestion. Do you know if this happened to be a recent change where this function was introduced?
https://docs.rs/wasmtime-wasi/21.0.1/wasmtime_wasi/runtime/fn.with_ambient_tokio_runtime.html#
If so, it may be the solution we need to enable on-event-loop WebAssembly execution.
In Extism, there's a check for some needed extra runtime initialization (see: https://github.com/extism/extism/blob/c3e912dffb97269a5f305b6258ae0992e1d6e5c4/runtime/src/plugin.rs#L630-L633)
Perhaps it was previously the case that wasmtime_wasi
assumed it could be executed from within an existing tokio runtime, and now it expects to be the parent tokio context?
This change landed in the 19 release https://github.com/bytecodealliance/wasmtime/blob/release-19.0.0/RELEASES.md#changed https://github.com/bytecodealliance/wasmtime/pull/7933 when the new wasmtime-wasi implementation was promoted to the default (root of crate) and the legacy wasi-common was removed as an export from wasmtime-wasi.
In the new wasmtime-wasi implementation, tokio is required to be used either externally to wasmtime when using add_to_linker_async
and the instantiate_async
/call_async
mode of entering wasm, or else it if you use add_to_linker_sync
it creates its own private tokio runtime to run that same async code in each import function call. Tokio wont let you create a new runtime on the same stack that an existing runtime is on. So, if you wish to use wasmtime-wasi through a the synchronous wasmtime interface, you'll have to do so on a new stack (via thread creation as Alex suggests) or else switch to using the async wasmtime interface.
Your other alternative is to use the wasi-common implementation, but that is approaching its EOL at this point, so we don't recommend that as a long term solution.
I think that this issue is currently working as intended in the sense that this is a consequence of the current design of wasmtime-wasi. Given that I'm going to close this, but @nilslice if there are still difficulties/issues remaining let me know and I can reopen too.
Thanks! We ended up switching back to wasi-common to fix.
I manage proto which utilizes a WASM plugin system powered by extism (which uses wasmtime under the hood). I was using extism v1.3, which was using wasmtime v17, without issue.
I'm trying to upgrade extism to v1.4, which bumps wasmtime to v21, but some plugin calls fail with the following:
This is very confusing because both extism and proto are interacting with wasmtime through sync calls, so I'm not entirely sure how we're hitting tokio/async stuff. However, proto is using tokio itself to power the CLI, but wasm calls are non-async.
I tried stepping through the panic with a debugger, but I was unable to uncover where exactly it's happening. The debugger would constantly jump between tokio worker threads and I would lose context.
Test Case
N/A, use steps below
Steps to Reproduce
git@github.com:moonrepo/proto.git
0.37-extism
cargo run -- install python 3.12.0 --log trace
Expected Results
Does not panic.
Actual Results
Consistently panics.
For context, this only happens with the proto python plugin, and not the other proto plugins. Here's the python plugin function that panics: https://github.com/moonrepo/python-plugin/blob/master/src/proto.rs#L143
Versions and Environment
Wasmtime version or commit: 21
Operating system: macos (but fails on all)
Architecture: arm64 (but fails on all)
Extra Info
PR of failing builds: https://github.com/moonrepo/proto/actions/runs/9504911118/job/26198611886?pr=515