nix (Apr 25 2026 at 20:13): nix (Apr 25 2026 at 20:13):Hello there!
I'm building a deterministic simulation testing tool that runs services compiled to wasm32-wasip2 inside Wasmtime, with host-controlled I/O via WIT interfaces, and injects faults at the host function boundary to find concurrency and crash-recovery bugs.
The pattern I really want to support is branching exploration: run execution to some interesting point, capture the full state, inject a fault, observe the outcome, restore the state, inject a different fault, repeat. The VM-based approaches achieve this via full VM snapshots.
What I think I need is a way to capture and clone the execution state of a paused instance from the host side - something like a Continuation::clone_suspended(), that produces an independent continuation resumable from the same point. I found this open issue: https://github.com/bytecodealliance/wasmtime/issues/3017 and reading through this other issue about stack switching (https://github.com/bytecodealliance/wasmtime/issues/10248), it seemed some stuff from there seems applicable here. And the "embedder API" seemed like the place to look into?
I imagine there's state on the instance stack that can't just be memcpy'd because there are references to original stack location (is not pinned).
Is that the right direction? Doing some work to support the #0248 issue further?
Hi, btw!
I'm Nícolas (go by nix usually), computer engineer from Polytechnic School of São Paulo, here in Brazil. I've been working professionally with Rust for about 3 years now, mostly at a fintech, 1 other year of python and java. Still learning and using Wasmtime - as a user - for now! Would be happy to help and contribute!
Chris Fallin (Apr 25 2026 at 22:59):Hi @nix -- I would say that everything in #3017 is still the current best source of information on what this would take. This is a very deep project that would require familiarity with the whole runtime and its invariants, as a simple-hack-level implementation (memcpy the whole stack, say) will run into a lot of issues -- e.g., mix of host and Wasm frames, with copying and re-executing a Rust stack frame being UB (this is equivalent to longjmp returning twice); pointer relocation if you restore to a different address; VM state being tied with Wasm state, and inability to snapshot the process as you execute within it, because the snapshot/restore driver is e.g. using the same heap allocator; and probably a lot more. I don't mean to discourage, just to say that this is a big research project, with a lot of unknowns, and no one here can give you a recipe for how to do it unfortunately. All the best!
nix (Apr 25 2026 at 23:09):Thanks Chris!
If I may, could the picture change for this interpreted Pulley backend? Or does that come with its own issues?
Alex Crichton (Apr 25 2026 at 23:32):Unfortunately, no, pulley is basically at the level of a CPU so it's got all the same problems that native architectures have, so Pulley will be just as much work as native backends
nix (Apr 26 2026 at 00:09):Got it — thanks Alex. Appreciate both of you taking the time on this.
Last updated: May 03 2026 at 22:13 UTC