<?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 call_async.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><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/call_async.rs#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:18:09 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
