Make CAddrMan fuzzing harness deterministic.
See doc/fuzzing.md for information on how to fuzz Bitcoin Core. Don't forget to contribute any coverage increasing inputs you find to the Bitcoin Core fuzzing corpus repo.
Happy fuzzing :)
Make CAddrMan fuzzing harness deterministic.
See doc/fuzzing.md for information on how to fuzz Bitcoin Core. Don't forget to contribute any coverage increasing inputs you find to the Bitcoin Core fuzzing corpus repo.
Happy fuzzing :)
review ACK 760029278c1dce2796605be0f0c368bd56ab8426
will test before merge
utACK 17a5f172fa9ec509b1c3f950ee8dfb6f025534d2
21 | @@ -22,12 +22,22 @@ void initialize() 22 | SelectParams(CBaseChainParams::REGTEST); 23 | } 24 | 25 | +class CAddrManDeterministic : public CAddrMan
nit: new code shouldn't use the c prefix
Just for my own personal understanding - why should the CAddrMan fuzzing harness be deterministic?
all testing should be deterministic, otherwise it is impossible to reliably reproduce bugs
Isn't that one of the reasons for fuzzing? That testers will initially fuzz different inputs and then highlight which inputs create an issue? Maybe I am misunderstanding what you mean by deterministic here...
Everyone runs the same unit and functional tests. But fuzz testers at least in theory try different inputs?
Generation of the seeds itself by the fuzz engine doesn't have to be deterministic. And for most fuzz engines it isn't (unless you ask them to).
So yes, fuzz testers will run different inputs during generation. However, if they discover a crash with one input, the crash should be reproducible when the same input is run again (even on a different machine)