* fuzz: Implement finer memory limits per-store This commit implements a custom resource limiter for fuzzing. Locally I was seeing a lot of ooms while fuzzing and I believe it was generally caused from not actually having any runtime limits for wasm modules. I'm actually surprised that this hasn't come up more on oss-fuzz more in reality, but with a custom store limiter I think this'll get the job done where we have an easier knob to turn for controlling the memory usage of fuzz-generated modules. For now I figure a 2gb limit should be good enough for limiting fuzzer execution. Additionally the "out of resources" check if instantiation fails now looks for the `oom` flag to be set instead of pattern matching on some error messages about resources. * Fix tests
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.