fuzz: Make CAddrMan fuzzing harness deterministic #20425

pull practicalswift wants to merge 1 commits into bitcoin:master from practicalswift:fuzzers-make-addrman-harness-deterministic changing 2 files +14 −3

practicalswift commented at 5:12 PM on November 19, 2020: contributor

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 :)
practicalswift renamed this:
~~fuzz: Make addrman fuzzing harness deterministic~~
fuzz: Make CAddrMan fuzzing harness deterministic
on Nov 19, 2020
MarcoFalke commented at 5:18 PM on November 19, 2020: member

review ACK 760029278c1dce2796605be0f0c368bd56ab8426

will test before merge
practicalswift force-pushed on Nov 19, 2020
fuzz: Make addrman fuzzing harness deterministic 17a5f172fa
practicalswift force-pushed on Nov 19, 2020
DrahtBot added the label Tests on Nov 19, 2020
practicalswift cross-referenced this on Nov 20, 2020 from issue fuzz: Avoid time-based "non-determinism" in fuzzing harnesses by using mocked GetTime() by practicalswift
Crypt-iQ commented at 5:12 PM on November 26, 2020: contributor

utACK 17a5f172fa9ec509b1c3f950ee8dfb6f025534d2

in src/test/fuzz/addrman.cpp:25 in 17a5f172fa

  21 | @@ -22,12 +22,22 @@ void initialize()
  22 |      SelectParams(CBaseChainParams::REGTEST);
  23 |  }
  24 |  
  25 | +class CAddrManDeterministic : public CAddrMan

MarcoFalke commented at 1:04 PM on December 1, 2020:

nit: new code shouldn't use the c prefix

MarcoFalke merged this on Dec 1, 2020
MarcoFalke closed this on Dec 1, 2020
michaelfolkson commented at 1:12 PM on December 1, 2020: contributor

Just for my own personal understanding - why should the CAddrMan fuzzing harness be deterministic?
MarcoFalke commented at 1:14 PM on December 1, 2020: member

all testing should be deterministic, otherwise it is impossible to reliably reproduce bugs
michaelfolkson commented at 1:19 PM on December 1, 2020: contributor

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?
MarcoFalke commented at 1:24 PM on December 1, 2020: member

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)
sidhujag referenced this in commit 342411c5e0 on Dec 1, 2020
MarcoFalke referenced this in commit 70150824dc on Dec 15, 2020
sidhujag referenced this in commit ecc8a3c3a4 on Dec 15, 2020
practicalswift deleted the branch on Apr 10, 2021
bitcoin locked this on Aug 16, 2022

Contributors

Labels

Linked (view graph)

#20437 fuzz: Avoid time-based "non-determinism" in fuzzing harnesses by using mocked GetTime()