0a020918b5
We've got some OOM fuzz test cases getting reported, but these aren't very interesting. The OOMs, after some investigation, are confirmed to be happening because the test is simply allocating thousands of instances with massive tables, quickly exceeding the 2GB memory threshold for fuzzing. This isn't really interesting because this is expected behavior if you instantiate these sorts of modules. This commit updates the fuzz test case generator to have a "prediction" for each module how much memory it will take to instantiate it. This prediction is then used to avoid instantiating new modules if we predict that it will exceed our memory limit. The limits here are intentionally very squishy and imprecise. The goal here is to still generate lots of interesting test cases, but not ones that simply exhaust memory trivially.
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.