Implements multiprocess fuzzing (and other features).
Closes https://github.com/ziglang/zig/issues/20803
Closes https://github.com/ziglang/zig/issues/22901
Closes #30969
New Features
Multiprocess Fuzzing
The fuzzer now is able to utilize multiple cores. This is controllable with the -j build option. Limited fuzzing still uses one core.
Fuzzing Infinite Mode
When provided multiple tests, the fuzzer now switches between them and prioritizes the most effective and interesting ones. Over time already explored tests will become barely run compared to tests yielding new inputs.
Crash Dumps
Crashing inputs are now saved to a file indicated by the crash message. It is recommended to use these files to reproduce the crash using std.testing.FuzzInputOptions.corpus and @embedFile.
Design
Each fuzzing process is assigned an instance id which has the following uses:
- In conjunction with the pc hash and running test index, they uniquely identify input files in the case of a crash.
- It is combined with the test seed for a unique rng seed.
- Instance 0 is solely responsible for syncing the filesystem corpus.
When new inputs are found, they are sent to the build server. It then distributes the new input to the other instances. Each instance has a concurrent poller managed by the test runner which sends received inputs to libfuzzer. (note that this is affected by #31718 and so can (rarely) deadlock)
For fuzzing infinite mode, the test runner now receives a list of tests from the build server. The fuzzer runs tests in batches of one second, approximated in cycles by the previous batch's run speed. Tests finding new inputs or with few runs are given a higher run chance. The baseline run chance is based off the recency of the last find and the number of pcs the test has hit.
Implements multiprocess fuzzing (and other features).
Closes https://github.com/ziglang/zig/issues/20803
Closes https://github.com/ziglang/zig/issues/22901
Closes #30969
## New Features
### Multiprocess Fuzzing
The fuzzer now is able to utilize multiple cores. This is controllable with the `-j` build option. Limited fuzzing still uses one core.
### Fuzzing Infinite Mode
When provided multiple tests, the fuzzer now switches between them and prioritizes the most effective and interesting ones. Over time already explored tests will become barely run compared to tests yielding new inputs.
### Crash Dumps
Crashing inputs are now saved to a file indicated by the crash message. It is recommended to use these files to reproduce the crash using `std.testing.FuzzInputOptions.corpus` and @embedFile.
## Design
Each fuzzing process is assigned an instance id which has the following uses:
* In conjunction with the pc hash and running test index, they uniquely identify input files in the case of a crash.
* It is combined with the test seed for a unique rng seed.
* Instance 0 is solely responsible for syncing the filesystem corpus.
When new inputs are found, they are sent to the build server. It then distributes the new input to the other instances. Each instance has a concurrent poller managed by the test runner which sends received inputs to libfuzzer. (note that this is affected by #31718 and so can (rarely) deadlock)
For fuzzing infinite mode, the test runner now receives a list of tests from the build server. The fuzzer runs tests in batches of one second, approximated in cycles by the previous batch's run speed. Tests finding new inputs or with few runs are given a higher run chance. The baseline run chance is based off the recency of the last find and the number of pcs the test has hit.