| #
fee9be21 |
| 09-Dec-2025 |
Alex Crichton <[email protected]> |
Add a new fuzzer focused on component-model-async events (#12119)
* Add a new fuzzer focused on component-model-async events
This commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtime
whic
Add a new fuzzer focused on component-model-async events (#12119)
* Add a new fuzzer focused on component-model-async events
This commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtime
which is focused on async events and interleavings of components using
the component-model-async proposal. This fuzzer works by having a
precompiled guest program which serves as the component to run. This
precompiled component has a custom `fuzz.wit` which is used to interface
with the fuzzer itself. The fuzzer is then a fuzz-generated sequence of
commands to send to the component which verifies that everything
executes correctly, has no panics, etc.
This fuzzer intends to stress async communication and task
infrastructure with component-model-async. Notably this does not stress
lifting/lowering or arbitrary type signatures. This does, however,
permute all of the following:
* Guest/host interactions (also guest/guest, host/host, etc).
* Async functions, both ready and pending.
* Future operations: reads, writes, cancellation, transfers, etc.
* Stream operations: reads, writes, cancellation, transfers, etc.
This is all throwing into a large "soup" and then asserted to work
correctly. There's a few gotchas here and there for how this fuzzer is
designed, such as some events requiring "yield N times to await this
event happening". This is required because Wasmtime is allowed to
non-deterministically select between a number of "ready events" and what
to dispatch.
This is not intended to be a one-size-fits-all fuzzer for
component-model-async. The recent enhancements to the `component_api`
fuzzer are intended to complement this fuzzer in terms of what's
stressed where internally.
* Review comments
show more ...
|