When taking a snapshot of coverage counters, round each counter down
to the nearest power of 2.
After coarsening, at most 1 bit per byte will be set. This lets the
coordinator use a coverage array as a mask that distinguish between
code that's executed many times for a given input and code that's
executed once or a few times. For example, if a byte in this array has
the value 12, it means the block has been executed at least 4 times
and at least 8 times with different inputs.
Also change the term "edge" to "bits" or just be more vague about how
coverage is represented.
Also add more code that may be "interesting" in test_fuzz_cache.
Change-Id: I67bf2adb298fb8efd7680b069a476c27e5fdbdae
Reviewed-on: https://go-review.googlesource.com/c/go/+/338829
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
When GODEBUG=fuzzdebug=1, log additional debug level information about
what the fuzzer is doing. This provides useful information for
investigating the operation and performance of the fuzzing engine, and
is necessary for profiling new fuzzing strategies.
Change-Id: Ic3e24e7a128781377e62785767a218811c3c2030
Reviewed-on: https://go-review.googlesource.com/c/go/+/324972
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
When instrumented packages intersect with the packages used by the
testing or internal/fuzz packages the coverage counters become noisier,
as counters will be triggered by non-fuzzed harness code.
Ideally counters would be deterministic, as there are many advanced
fuzzing strategies that require mutating the input while maintaining
static coverage.
The simplest way to mitigate this noise is to capture the coverage
counters as closely as possible to the invocation of the fuzz target
in the testing package. In order to do this add a new function which
captures the current values of the counters, SnapshotCoverage. This
function copies the current counters into a static buffer,
coverageSnapshot, which workerServer.fuzz can then inspect when it
comes time to check if new coverage has been found.
This method is not foolproof. As the fuzz target is called in a
goroutine, harness code can still cause counters to be incremented
while the target is being executed. Despite this we do see
significant reduction in churn via this approach. For example,
running a basic target that causes strconv to be instrumented for
500,000 iterations causes ~800 unique sets of coverage counters,
whereas by capturing the counters closer to the target we get ~40
unique sets.
It may be possible to make counters completely deterministic, but
likely this would require rewriting testing/F.Fuzz to not use tRunner
in a goroutine, and instead use it in a blocking manner (which I
couldn't figure out an obvious way to do), or by doing something even
more complex.
Change-Id: I95c2f3b1d7089c3e6885fc7628a0d3a8ac1a99cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/320329
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
This change updates the go command behavior when
fuzzing to instrument the binary for code coverage,
and uses this coverage in the fuzzing engine to
determine if an input is interesting.
Unfortunately, we can't store and use the coverage
data for a given run of `go test` and re-use it
the next time we fuzz, since the edges could have
changed between builds. Instead, every entry in
the seed corpus and the on-disk corpus is run
by the workers before fuzzing begins, so that the
coordinator can get the baseline coverage for what
the fuzzing engine has already found (or what
the developers have already provided).
Users should run `go clean -fuzzcache` before
using this change, to clear out any existing
"interesting" values that were in the cache.
Previously, every single non-crashing input was
written to the on-disk corpus. Now, only inputs
that actually expand coverage are written.
This change includes a small hack in
cmd/go/internal/load/pkg.go which ensures that the Gcflags
that were explicitly set in cmd/go/internal/test/test.go
don't get cleared out.
Tests will be added in a follow-up change, since
they will be a bit more involved.
Change-Id: Ie659222d44475c6d68fa4a35d37c37cab3619d71
Reviewed-on: https://go-review.googlesource.com/c/go/+/312009
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>
This CL makes two main changes to allow internal/fuzz to support
-d=libfuzzer instrumentation:
1. It extends cmd/link to define _counters and _ecounters symbols so
internal/fuzz can find the coverage counters.
2. It adds "trace" stub functions that implement the ABI expected by
cmd/compile for comparison instrumentation.
N.B., that -tags=libfuzzer should *not* be set, so that
internal/fuzz's trace routines will be used instead of runtime's
libfuzzer trampolines.
Also, the current implementation doesn't support multi-module builds
(i.e., compiling a Go program that spans multiple .so/.dll files).
Presumably this isn't an issue, since "go test -fuzz" will need to
recompile the binary with instrumentation anyway so it can make sure
to always use a single-module build. But we can revisit this if
necessary.
Change-Id: I9b1619119ab7477bebcfd5988b4b60499a7ab0d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/308289
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This change only includes a stub for the function
which will hook into the runtime to expose
coverage instrumentation while we're fuzzing.
Previously, we discussed an exported API named
FuzzCoverage, but since this is within the
internal/fuzz package, simply naming it coverage
seems appropriate.
Change-Id: Iba3240e53e0c4c434e937aa9bb1711a44fec9975
Reviewed-on: https://go-review.googlesource.com/c/go/+/308191
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
