| 0b9ff9bf | 19-Nov-2025 |
Alex Crichton <[email protected]> |
Add async to the component_api fuzzer (#12047)
This commit extends the preexisting `component_api` fuzzer in Wasmtime
to support `async`. This required a fair bit of refactoring to how the
fuzzer wo
Add async to the component_api fuzzer (#12047)
This commit extends the preexisting `component_api` fuzzer in Wasmtime
to support `async`. This required a fair bit of refactoring to how the
fuzzer worked but the basic idea remains the same. This fuzzer
generates:
* An arbitrary component-model type signature (minus
resources/futures/streams)
* A component which imports a function of this signature from the host
and exports a function of this signature to the host.
* Internally the export is implemented with a component `caller` that
imports/exports this function signature.
* The `caller` component is instantiated with a `callee` component that
imports/exports this function signature.
* The `callee` component is instantiated with the host.
In essence a component model value is threaded into a component, to
another composed component, then back out to the host. The return value
then makes its way back through the same channel. The fuzz test ensures
that the parameters received in the host import are the same as those
passed to the export. Additionally the return value of the export is
ensured to be the same as the one that the host import returned. In
essence this is testing ABI handling in Wasmtime to ensure that
composition works correctly in addition to lifting/lowering code.
This fuzzer additionally has a "static" and "dynamic" mode where, at
compile time, N components are generated with different signatures and
use the "typed" APIs of Wasmtime. For "dynamic" `Val` is used to test
and arbitrary components are generated at fuzz-time. The fuzzer finally
executes this roundtrip in a loop multiple times in one fuzz test case
to test different runtime-shapes of values in addition to
compile-time-shapes of values.
The main addition in this commit is to extend all of this with the async
ABI. The following knobs were added and implemented:
* The function type used for the root component export, the function
between the composed components, and the function imported from the
host all have the ability to be an `async` function type now.
* The lifts/lowers, in all locations, can be configured with the various
ABIs supported (e.g. sync, async-callback, or async-stackful for
lifts, and sync/async for lowers).
* Like before the string encoding can be varied between the components
as well.
This is intended to stress combining different flavors of ABI with
different behaviors to ensure that all the various paths throughout
Wasmtime and such are hit. The goal of this fuzzer is to stress ABI
lifting/lowering, so this is not handling much related to async event
scheduling (that's for a future fuzzer).
In a follow-up commit I hope to extend this fuzzer with some async event
scheduling nonetheless. For example the fuzzer will generate an async
yield point before/after calling `task.return` or before/after calling
the host import. That is intended to stress `first_poll`-vs-not behavior
as it relates to ABI handling. None of that is yet implemented and for
this fuzzer async calls are assumed to always succeed immediately for now.
show more ...
|