History log of /wasmtime-44.0.1/fuzz/fuzz_targets/misc.rs (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0
# 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 ...


Revision tags: v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0
# 6047d27e 28-Jul-2025 Khagan (Khan) Karimov <[email protected]>

Add fuzzer integration for gc/mutatis (#11290)

* Add fuzzer integration for gc/mutatis

* Replace bincode with postcard. Inline fuzz_mutate. Address other small comments

* Update Cargo.lock after r

Add fuzzer integration for gc/mutatis (#11290)

* Add fuzzer integration for gc/mutatis

* Replace bincode with postcard. Inline fuzz_mutate. Address other small comments

* Update Cargo.lock after rebase

* Update rng.gen to rng.fill to avoid deprecation failure

* Remove table_ops from misc. Update fuzz_target. Keep Arbitrary impl it gives some dependecy error. Will be addressed later

* Update Cargo.lock to match upstream/main

* Regenerate Cargo.lock after rebase and dependency changes

* Reset Cargo.lock to upstream/main to preserve cargo-deny compatibility

* Update dependencies

---------

Co-authored-by: Khagan Karimov <[email protected]>

show more ...


Revision tags: v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0
# 90ac295e 19-May-2025 Alex Crichton <[email protected]>

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...


Revision tags: v32.0.0
# 94ec88ea 08-Apr-2025 Chris Fallin <[email protected]>

Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)

* Cranelift: initial try_call / try_call_indirect (exception) support.

This PR adds `try_call` and `try_call_indirect`

Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)

* Cranelift: initial try_call / try_call_indirect (exception) support.

This PR adds `try_call` and `try_call_indirect` instructions, and
lowerings on four of five ISAs (x86-64, aarch64, riscv64, pulley; s390x
has its own non-shared ABI code that will need separate work).

It extends CLIF to support these instructions as new kinds of branches,
and extends block-calls to accept `retN` and `exnN` block-call args that
carry the normal return values or exception payloads (respectively) into
the appropriate successor blocks.

It wires up the "normal return path" so that it continues to work.
It updates the ABI so that unwinding is possible without an initial
register state at throw: specifically, as per our RFC, all registers are
clobbered. It also includes metadata in the `MachBuffer` that describes
exception-catch destinations. However, no unwinder exists to interpret
these catch-destinations yet, so they are untested.

* Add try_call_indirect lowering as well.

show more ...


Revision tags: v31.0.0
# 1ea710d6 14-Mar-2025 Andrew Brown <[email protected]>

asm: fuzz `cranelift-codegen-x64` in the `misc` target (#10403)

As discussed previously, this change adds fuzzing for the x64 assembler
to the melting pot target, `misc`, in order to get at least so

asm: fuzz `cranelift-codegen-x64` in the `misc` target (#10403)

As discussed previously, this change adds fuzzing for the x64 assembler
to the melting pot target, `misc`, in order to get at least some fuzzing
cycles on OSS-Fuzz.

show more ...


# 840f5448 12-Mar-2025 Alex Crichton <[email protected]>

Consolidate some fuzzers into one (#10385)

This commit consolidates a number of fuzzers that we have in Wasmtime
into a single fuzzer. This follows the pattern of [wasm-tools's `run`
fuzzer][tools]

Consolidate some fuzzers into one (#10385)

This commit consolidates a number of fuzzers that we have in Wasmtime
into a single fuzzer. This follows the pattern of [wasm-tools's `run`
fuzzer][tools] where the first byte in the fuzz input says which fuzzer
to run and then the rest of the input is the input to the fuzzer. This
is intended to improve our time-slicing on OSS-Fuzz where less important
fuzzers don't hog time from the "important fuzzers" such as
`differential`. Some minor-ish fuzzers have been folded in to this new
fuzzer, but we can also always move things around as needed

[tools]: https://github.com/bytecodealliance/wasm-tools/blob/main/fuzz/fuzz_targets/run.rs

show more ...