[dev.fuzz] skip running seed corpus as ordinary test when fuzzing the target #48296
Labels
Milestone
Comments
katiehockman
added
the
NeedsFix
This was referenced Sep 9, 2021
|
Change https://golang.org/cl/349630 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 16, 2021
This change refactors some of the code to support skipping a run of the seed corpus by the go command before runFuzzing occurs. Previously, the go command would run all seed corpus for all targets that match the provided `run` argument. This will be redundant when fuzzing a target. Now, the seed corpus is only run by targets other than the one that's about to be fuzzed, and the worker handles running and reporting issues with the seed corpus. Part of the logic that needed close inspection is what to do if a failure occurs during a testing-only or coverage-only fail. If the input is already in the seed corpus, the fuzzing engine shouldn't add it. If the input is currently in the cache, then it should be written to testdata. In all cases, if an error occurs, we need to report this to the user with enough information for them to debug it. This uncovered some issues with our code when fuzzing without instrumentation, and when -run=None was provided. There are some logic fixes in this change, and some small refactors. Fixes #48327 Fixes #48296 Change-Id: I9ce2be0219c5b09277ddd308df8bc5a46d4558fa Reviewed-on: https://go-review.googlesource.com/c/go/+/349630 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Related to #46222
From @rsc: "check whether a fuzz test matches the -fuzz pattern and if so not run just that one test function as an ordinary test case, because that duplicates work and also because the fuzzing harness can do a better job with infinite loops."
We already have to run all of the seed corpus anyway when
-fuzzis set in order to get baseline coverage data. The only time we don't is if instrumentation wasn't done (e.g. someone manually built the test withgo test -c). We could refactor the code to make sure the coordinator always has the workers run this seed corpus and correctly report any failing seed corpus in this setup step.This won't actually change the underlying UX of fuzzing, other than to have fewer lines printed if run with
-vsince each seed corpus will no longer be run as an individual test.The text was updated successfully, but these errors were encountered: