<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in fuzz_targets</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>fee9be21 - Add a new fuzzer focused on component-model-async events (#12119)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#fee9be21</link>
        <description>Add a new fuzzer focused on component-model-async events (#12119)* Add a new fuzzer focused on component-model-async eventsThis commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtimewhich is focused on async events and interleavings of components usingthe component-model-async proposal. This fuzzer works by having aprecompiled guest program which serves as the component to run. Thisprecompiled component has a custom `fuzz.wit` which is used to interfacewith the fuzzer itself. The fuzzer is then a fuzz-generated sequence ofcommands to send to the component which verifies that everythingexecutes correctly, has no panics, etc.This fuzzer intends to stress async communication and taskinfrastructure with component-model-async. Notably this does not stresslifting/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 &quot;soup&quot; and then asserted to workcorrectly. There&apos;s a few gotchas here and there for how this fuzzer isdesigned, such as some events requiring &quot;yield N times to await thisevent happening&quot;. This is required because Wasmtime is allowed tonon-deterministically select between a number of &quot;ready events&quot; and whatto dispatch.This is not intended to be a one-size-fits-all fuzzer forcomponent-model-async. The recent enhancements to the `component_api`fuzzer are intended to complement this fuzzer in terms of what&apos;sstressed where internally.* Review comments

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/misc.rs</description>
        <pubDate>Tue, 09 Dec 2025 19:00:00 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>46780983 - Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#46780983</link>
        <description>Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)* Exceptions: add exception-specific (command-sequence) fuzzer.This fuzzer uses a description of a set of &quot;scenarios&quot;, arbitrarilygenerated, to produce a specific kind of module that tests throw/catchbehavior. The module contains a chain of functions that invoke eachother; one will throw, and the rest may have catch clauses that do ordo not catch.* Review feedback.

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/exception_ops.rs</description>
        <pubDate>Wed, 01 Apr 2026 22:00:00 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>b6f59f05 - Split modules (#11993)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#b6f59f05</link>
        <description>Split modules (#11993)* Split GC to different modules and rename table_ops to gc_ops* Remove table_ops from fuzz_targets. Renamed to gc_ops* Address formatting failures

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/gc_ops.rs</description>
        <pubDate>Fri, 07 Nov 2025 17:00:00 +0000</pubDate>
        <dc:creator>Khagan (Khan) Karimov &lt;127453117+khagankhan@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>83575995 - Enable async support in wast tests (#10366)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#83575995</link>
        <description>Enable async support in wast tests (#10366)* Enable async support in wast testsThis commit updates the `wasmtime-wast` crate to conditionally use the`Config::async_support` mode of Wasmtime, notably executing`instantiate_async` and `call_async`. At this time no actual concurrencyis supported and everything is immediately await&apos;d on via `block_on` anda local single-thread tokio runtime.The motivation for this commit is that in the upcoming implementation ofWASIp3 async will effectively be the only way to invoke components.Furthermore to test these components we&apos;re wanting to use async APIs asthe root of invocations for writing `*.wast` tests for testingcomponent-model async features.In enabling this support this commit additionally updates the`wast_tests` fuzzer to execute all tests both with and without async.Effectively the async configuration is now a fuzz option, meaning thatall tests are being executed with async now as well to ensure that theywork (yay!).The `--test wast` testing mode and `wasmtime wast` CLI command are bothupdated to unconditionally use async. There should be no loss in testcoverage due to the fuzzer update, and right now knobs aren&apos;t providedto conditionally use sync in these two modes, again because it&apos;scurrently expected that this won&apos;t be able to run component model asynctests, so the defaults are changing.* Fix building wasmtime-wast in isolation

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/wast_tests.rs</description>
        <pubDate>Tue, 11 Mar 2025 15:00:00 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>e4b88760 - Fuzzing: Check that Wasm compilation is deterministic (#6704)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#e4b88760</link>
        <description>Fuzzing: Check that Wasm compilation is deterministic (#6704)

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/compile.rs</description>
        <pubDate>Fri, 07 Jul 2023 17:00:00 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>b4ecea38 - Add a fuzzer for async wasm (#8440)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#b4ecea38</link>
        <description>Add a fuzzer for async wasm (#8440)* Add a fuzzer for async wasmThis commit revives a very old branch of mine to add a fuzzer forWasmtime in async mode. This work was originally blocked onllvm/llvm-project#53891 and while that&apos;s still an issue it now containsa workaround for that issue. Support for async fuzzing required a gooddeal of refactorings and changes, and the highlights are:* The main part is that new intrinsics,  `__sanitizer_{start,finish}_fiber_switch` are now invoked around the  stack-switching routines of fibers. This only works on Unix and is set  to only compile when ASAN is enabled (otherwise everything is a noop).  This required refactoring of things to get it all in just the right  way for ASAN since it appears that these functions not only need to be  called but more-or-less need to be adjacent to each other in the code.  My guess is that while we&apos;re switching ASAN is in a &quot;weird state&quot; and  it&apos;s not ready to run arbitrary code.* Stacks are a problem. The above issue in LLVM outlines how stacks  cannot be deallocated at this time because if the deallocated virtual  memory is later used for the heap then ASAN will have a false positive  about stack overflow. To handle this stacks are specially handled in  asan mode by using a special allocation path that never deallocates  stacks. This logic additionally applies to the pooling allocator which  uses a different stack allocation strategy with ASAN.With all of the above a new fuzzer is added. This fuzzer generates anarbitrary module, selects an arbitrary means of async (e.g.epochs/fuel), and then tries to execute the exports of the module withvarious values. In general the fuzzer is looking for crashes/panics asopposed to correct answers as there&apos;s no oracle here. This is alsointended to stress the code used to switch on and off stacks.* Fix non-async build* Remove unused import* Review comments* Fix compile on MIRI* Fix Windows build

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/call_async.rs</description>
        <pubDate>Tue, 23 Apr 2024 19:00:00 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>5730c760 - Improve `Config`-related coverage of `component_api` (#12049)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#5730c760</link>
        <description>Improve `Config`-related coverage of `component_api` (#12049)This commit improves the preexisting `component_api` fuzz target to usearbitrary `Config` data. This, for example, helps exercise Pulley inaddition to native. In general this also helps stress and ensure that noconfig knobs are accidentally breaking ABI assumptions.

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/component_api.rs</description>
        <pubDate>Fri, 21 Nov 2025 17:00:00 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>c3a6060b - Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#c3a6060b</link>
        <description>Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)* Polyfill `ToWasmtimeResult` and add eventually-necessary call sitesThis commit polyfills `wasmtime_internal_error::ToWasmtimeResult` in`wasmtime_environ`, adds the cargo feature plumbing that will eventually connectto the `&quot;wasmtime_internal_error/anyhow&quot;` cargo feature but for now justconfigures this polyfill, and adds uses of the polyfill at all the sites thatwill be necessary once we swap out `anyhow` for`wasmtime_internal_error`. Currently, the polyfill is just an identity function,because `wasmtime::Result`/`wasmtime_environ::error::Result` is just anothername for `anyhow::Result`. Once we do move away from `anyhow`, however, thatwill no longer be the case, and these uses will do the necessary conversion.My goal with landing this as an incremental commit is to make it so that theactual commit that does the error crate swap out can be as close to _just_ the`Cargo.toml` dependency change, without any other code changes as much aspossible. This, in turn, means that swap out should be super easy to revert, ifnecessary.* Add a couple more `.to_wasmtime_result()` invocations in fuzz code* Revert &quot;Add a couple more `.to_wasmtime_result()` invocations in fuzz code&quot;This reverts commit b33696e5f63f7eed731ca9dad10fec5e55a550d3.* Move cranelift fuzz targets back to anyhow* Fix cargo feature enablement for explorer

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/cranelift-fuzzgen.rs/wasmtime-44.0.1/fuzz/fuzz_targets/cranelift-icache.rs</description>
        <pubDate>Tue, 13 Jan 2026 18:00:00 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>332b4ce6 - fuzz: Enable winch-aarch64 (#12646)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#332b4ce6</link>
        <description>fuzz: Enable winch-aarch64 (#12646)As of https://github.com/bytecodealliance/wasmtime/pull/11051, Winchsupports all of Core Wasm on aarch64. This commit enables fuzzingrespectively.

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/differential.rs</description>
        <pubDate>Tue, 24 Feb 2026 16:00:00 +0000</pubDate>
        <dc:creator>Sa&#250;l Cabrera &lt;saulecabrera@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>04c03b31 - Update the wasm-tools family of crates (#7921)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#04c03b31</link>
        <description>Update the wasm-tools family of crates (#7921)* Update the wasm-tools family of cratesPulling in some updates to improve how WIT is managed in thisrepository. No changes just yet, however, just pulling in the updatesfirst.* Fix tests* Fix fuzzer build

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/instantiate-many.rs</description>
        <pubDate>Mon, 12 Feb 2024 23:00:00 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/fuzz/fuzz_targets/#90ac295e</link>
        <description>Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it&apos;s possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition

            List of files:
            /wasmtime-44.0.1/fuzz/fuzz_targets/instantiate.rs</description>
        <pubDate>Mon, 19 May 2025 16:00:00 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
