f425eb7ea5
Per-`Store` allocations are already limited with the `StoreLimits` structure while fuzzing to ensure fuzz targets don't allocate more than 1GB of memory, but the `instantiate-many` fuzzer created many separate stores which each had their own limit, meaning that the 2GB limit of fuzzing could be pretty easily reached. This commit fixes the issue by making `StoreLimits` a shareable type via `Rc` to ensure the same limits can be applied to all stores created within a fuzz run, globally limiting the memory even across stores to 1GB.
Fuzzing Infrastructure for Wasmtime
This crate provides test case generators and oracles for use with fuzzing.
These generators and oracles are generally independent of the fuzzing engine
that might be using them and driving the whole fuzzing process (e.g. libFuzzer
or AFL). As such, this crate does not contain any actual fuzz targets
itself. Those are generally just a couple lines of glue code that plug raw input
from (for example) libFuzzer into a generator, and then run one or more
oracles on the generated test case.
If you're looking for the actual fuzz target definitions we currently have, they
live in wasmtime/fuzz/fuzz_targets/* and are driven by cargo fuzz and
libFuzzer.