aboutsummaryrefslogtreecommitdiff
path: root/src/internal/fuzz/fuzz.go
AgeCommit message (Collapse)Author
2024-03-26all: fix a large number of commentscui fliter
Partial typo corrections, following https://go.dev/wiki/Spelling Change-Id: I2357906ff2ea04305c6357418e4e9556e20375d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/573776 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2023-04-18cmd/go: add check for unknown godebug settingRuss Cox
A //go:debug line mentioning an unknown or retired setting should be diagnosed as making the program invalid. Do that. We agreed on this in the proposal but I forgot to implement it. Change-Id: Ie69072a1682d4eeb6866c02adbbb426f608567c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/476280 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-16internal/fuzz: fix debug statementRoland Shoemaker
Meant to check if the slice was empty, accidentally dumped the entire slice to stdout... Change-Id: I968cb2f20ffb006e4dcfea65a1bad794aac05d17 Reviewed-on: https://go-review.googlesource.com/c/go/+/476795 Auto-Submit: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org>
2023-03-16internal/fuzz: more debug loggingRoland Shoemaker
Change-Id: I2c36baf423dde419aaa940ce9308088f3bf431f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/476718 Auto-Submit: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
2023-03-15internal/fuzz: improve debugging messagesRoland Shoemaker
Also enable debugging information in TestScript/test_fuzz_cov, which hits a deadlock on builders, but I am unable to trigger locally. This should make it somewhat easier to track down where the issue actually is. Updates #51484 Change-Id: I98124f862242798f2d9eba15cacefbd02924cfe2 Reviewed-on: https://go-review.googlesource.com/c/go/+/476595 Auto-Submit: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
2023-03-10internal/fuzz: avoid deadlock on duplicate entries with exec limitRoland Shoemaker
If there was a execution limit enabled, and a result put us beyond that limit, but the result expanded coverage *and* was a duplicate of an entry already in the cache, the check if we were passed the limit would be skipped. Since this check was inside the result check body, and we would no longer send any new inputs, we'd never get to that check again, causing the coordinator to just sit in an infinite loop. This moves the check up to the top of the coordinator loop, so that it is checked after every result is processed. Also add a cmd/go TestScript regression test which triggered this case much more frequently. Updates #51484 Change-Id: I7a2181051177acb853c1009beedd334a40796177 Reviewed-on: https://go-review.googlesource.com/c/go/+/475196 Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-11-14internal/godebug: define more efficient APIRuss Cox
We have been expanding our use of GODEBUG for compatibility, and the current implementation forces a tradeoff between freshness and efficiency. It parses the environment variable in full each time it is called, which is expensive. But if clients cache the result, they won't respond to run-time GODEBUG changes, as happened with x509sha1 (#56436). This CL changes the GODEBUG API to provide efficient, up-to-date results. Instead of a single Get function, New returns a *godebug.Setting that itself has a Get method. Clients can save the result of New, which is no more expensive than errors.New, in a global variable, and then call that variable's Get method to get the value. Get costs only two atomic loads in the case where the variable hasn't changed since the last call. Unfortunately, these changes do require importing sync from godebug, which will mean that sync itself will never be able to use a GODEBUG setting. That doesn't seem like such a hardship. If it was really necessary, the runtime could pass a setting to package sync itself at startup, with the caveat that that setting, like the ones used by runtime itself, would not respond to run-time GODEBUG changes. Change-Id: I99a3acfa24fb2a692610af26a5d14bbc62c966ac Reviewed-on: https://go-review.googlesource.com/c/go/+/449504 Run-TryBot: Russ Cox <rsc@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-10-17internal/fuzz: write shorter testdata corpus file namesRuss Cox
The only purpose of using the SHA256 in the file name is collision avoidance. Using just the first 64 bits (16 hex digits) will be more than enough, unless people start storing billions of test cases in their corpora. The shorter names are nicer for just about everything: command lines, repository listings, and so on. Change-Id: I67c760023bed85ba3ffd4f8058f86ef778322ba7 Reviewed-on: https://go-review.googlesource.com/c/go/+/443335 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Peter Weinberger <pjw@google.com> Run-TryBot: Russ Cox <rsc@golang.org>
2022-09-28internal: use bytes.Clonecuiweixie
Change-Id: Ia96ddd520a7bd2fd53bff55315c6fac04ae96a2f Reviewed-on: https://go-review.googlesource.com/c/go/+/435282 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
2022-09-20all: replace package ioutil with os and io in srcAndy Pan
For #45557 Change-Id: I56824135d86452603dd4ed4bab0e24c201bb0683 Reviewed-on: https://go-review.googlesource.com/c/go/+/426257 Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Andy Pan <panjf2000@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-02-04internal/fuzz: change meaning of "total" in outputKatie Hockman
Fixes #51023 Change-Id: I7dd9f7c696e15ba9c6c887d4c4e0f4d281a82b17 Reviewed-on: https://go-review.googlesource.com/c/go/+/383414 Trust: Katie Hockman <katie@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-02-02internal/fuzz: small cleanupsKatie Hockman
Change-Id: I9fc12f352d57db776d176990277e104f64f9908d Reviewed-on: https://go-review.googlesource.com/c/go/+/382238 Reviewed-by: Julie Qiu <julie@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-02-01internal/fuzz: properly handle duplicates during cache loadingRoland Shoemaker
When loading the corpus, if the cache contained an entry which was a duplicate of an entry added using f.Add, coordinator.addCorpusEntries would return early, ignoring everything after this entry in the cache. Instead, skip duplicates as intended, and continue to load the rest of the cache. Fixes #50913 Change-Id: I3a64b93cbb217c5c364a9f8d0005752e9e9d10ff Reviewed-on: https://go-review.googlesource.com/c/go/+/381960 Trust: Katie Hockman <katie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-01-27internal/fuzz: centralize corpus entry additionRoland Shoemaker
Adds an addCorpusEntry method to coordinator which manages checking for duplicate entries, writing entries to the cache directory, and adding entries to the corpus. Also moves readCache to be a method on the coordinator. Fixes #50606 Change-Id: Id6721384a2ad1cfb4c5471cf0cd0a7510d250a6c Reviewed-on: https://go-review.googlesource.com/c/go/+/360394 Trust: Katie Hockman <katie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-20all: fix spelling errors found by misspellDan Kortschak
Change-Id: Icedd0c3d49259d5aee249ecb33374e9b78e0c275 Reviewed-on: https://go-review.googlesource.com/c/go/+/373376 Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-11-11all: update terminology for fuzzingKatie Hockman
This change doesn't modify any functionality. It also doesn't update all of the comments and variable names of the internal code, but everything user facing should be correct. Updates #49185 Change-Id: Ia8b2c94b89ba45897c4085ea0c17a3d8896f7ec7 Reviewed-on: https://go-review.googlesource.com/c/go/+/362794 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2021-11-04internal/fuzz: improve minimizing messageKatie Hockman
In order to know the actual number of bytes of the entire corpus entry, the coordinator would likely need to unmarshal the bytes and tally up the length. That's more work than it is worth, so this change just clarifies that the printed # of bytes is the length of the entire file, not just the entry itself. Fixes #48989 Change-Id: I6fa0c0206a249cefdf6335040c560ec0c5a55b4a Reviewed-on: https://go-review.googlesource.com/c/go/+/361414 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-11-03internal/fuzz: improve error for mismatched typesKatie Hockman
Fixes #48635 Change-Id: Ia3cde119d5eb31bc771fe3a39acb2372dbd988ff Reviewed-on: https://go-review.googlesource.com/c/go/+/361114 Trust: Katie Hockman <katie@golang.org> Trust: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-11-02net/netip: add new IP address packageBrad Fitzpatrick
Co-authored-by: Alex Willmer <alex@moreati.org.uk> (GitHub @moreati) Co-authored-by: Alexander Yastrebov <yastrebov.alex@gmail.com> Co-authored-by: David Anderson <dave@natulte.net> (Tailscale CLA) Co-authored-by: David Crawshaw <crawshaw@tailscale.com> (Tailscale CLA) Co-authored-by: Dmytro Shynkevych <dmytro@tailscale.com> (Tailscale CLA) Co-authored-by: Elias Naur <mail@eliasnaur.com> Co-authored-by: Joe Tsai <joetsai@digital-static.net> (Tailscale CLA) Co-authored-by: Jonathan Yu <jawnsy@cpan.org> (GitHub @jawnsy) Co-authored-by: Josh Bleecher Snyder <josharian@gmail.com> (Tailscale CLA) Co-authored-by: Maisem Ali <maisem@tailscale.com> (Tailscale CLA) Co-authored-by: Manuel Mendez (Go AUTHORS mmendez534@...) Co-authored-by: Matt Layher <mdlayher@gmail.com> Co-authored-by: Noah Treuhaft <noah.treuhaft@gmail.com> (GitHub @nwt) Co-authored-by: Stefan Majer <stefan.majer@gmail.com> Co-authored-by: Terin Stock <terinjokes@gmail.com> (Cloudflare CLA) Co-authored-by: Tobias Klauser <tklauser@distanz.ch> Fixes #46518 Change-Id: I0041f9e1115d61fa6e95fcf32b01d9faee708712 Reviewed-on: https://go-review.googlesource.com/c/go/+/339309 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Trust: Brad Fitzpatrick <bradfitz@golang.org>
2021-11-01internal/fuzz: don't add duplicate corpus entriesRoland Shoemaker
If a identical input is already present in the corpus, don't re-add it. This may happen when the same input produces a different coverage map, causing the coordinator to think it has found a new input. This fixes a race between reading/writing cached inputs. Fixes #48721 Change-Id: I4807602f433c2b99396d25ceaa58b827796b3555 Reviewed-on: https://go-review.googlesource.com/c/go/+/359755 Trust: Roland Shoemaker <roland@golang.org> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Katie Hockman <katie@golang.org>
2021-10-26internal/fuzz: tiny refactor+fixKatie Hockman
Change-Id: I8db9c31ead3e5905b7f9d1faed36555e8aaa00cd Reviewed-on: https://go-review.googlesource.com/c/go/+/358054 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Julie Qiu <julie@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-10-15internal/fuzz: fix bugs with minimizationKatie Hockman
This pulls in some code and tests from CL 353355. This change makes some refactors for when we read to and write from memory during minimization. That fixes a bug when minimizing interesting inputs. Now, if an error occurs while minimizing an interesting input, that value will continue to be minimized as a crash, and returned to the user. This change also allows minimization of a crash that occurred during the warmup phase. We don't want to minimize failures in the seed corpus, but if an entry in the cache causes a new failure, then there's no compelling reason why we shouldn't try to minimize it. Fixes #48731 Change-Id: I7262cecd8ea7ae6fdf932f3a36db55fb062a1f2a Reviewed-on: https://go-review.googlesource.com/c/go/+/355691 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2021-10-12internal/fuzz: fix -fuzzminimizetime with 'x' bugKatie Hockman
Fixes #48928 Change-Id: I3825ec615ab5fc19389ef4c10ad1042005a3761c Reviewed-on: https://go-review.googlesource.com/c/go/+/355450 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-10-12testing: fix -run behavior with fuzz testsKatie Hockman
This change fixes some issues with -run, and the subsequent command line output when running in verbose mode. It replaces CorpusEntry.Name with CorpusEntry.Path, and refactors the code accordingly. This change also adds a lot of additional tests which check explicit command line output when fuzz targets are run without fuzzing. This will be important to avoid regressions. Updates #48149 Change-Id: If34b1f51db646317b7b51c3c38ae53231d01f568 Reviewed-on: https://go-review.googlesource.com/c/go/+/354632 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>
2021-10-07internal/fuzz: log that minimization is occurringKatie Hockman
Previously, when fuzzing for a period of time, the command line output would look something like this: fuzz: minimizing 34995-byte crash input... fuzz: elapsed: 3s, execs: 13821 (4604/sec), new interesting: 0 (total: 1) fuzz: elapsed: 6s, execs: 13821 (2303/sec), new interesting: 0 (total: 1) fuzz: elapsed: 9s, execs: 13821 (1535/sec), new interesting: 0 (total: 1) --- FAIL: FuzzFoo (9.05s) This is the same output it has while fuzzing, so if minimization runs for a long time (default allows 1 minute), then it looks like minimization is hanging. It's also confusing that the execs/sec would continually decrease. Now, when minimization is running, the command line output will look something like this: fuzz: minimizing 34995-byte crash input... fuzz: elapsed: 3s, minimizing fuzz: elapsed: 6s, minimizing fuzz: elapsed: 9s, minimizing fuzz: elapsed: 9s, minimizing --- FAIL: FuzzFoo (9.05s) The final "fuzz: elapsed: 6s, minimizing" could be printed twice because we always print one final log to the command line before we exit. Updates #48820 Change-Id: Ie5b9fde48b8d4e36e13a81ae50a6d69bf4d0dbe3 Reviewed-on: https://go-review.googlesource.com/c/go/+/354371 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-10-06internal/fuzz: log average execs/sec since last logKatie Hockman
This change also fixes a bug with calculating the total interesting count. When fuzzing with an empty corpus, the fuzzing engine adds an starting corpus value in that run in order to start fuzzing. That meant that the interesting total count was off by one: it would start at 1, even though the cache was empty. Added some tests for this as well. Fixes #48787 Change-Id: I47acf96f0a0797214ebb24a95366d8460bf303bc Reviewed-on: https://go-review.googlesource.com/c/go/+/354150 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> Reviewed-by: Roland Shoemaker <roland@golang.org>
2021-10-04internal/fuzz: print size of interesting cacheAmelia Downs
This change updates the log lines to clarify that the printed interesting count is only for newly discovered cache entries, and prints the total cache size. It only prints information about interesting entries when coverageEnabled is true. Fixes #48669 Change-Id: I2045afc204764c1842d323e8ae42016fb21b6fb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/353172 Trust: Michael Knyszek <mknyszek@google.com> Trust: Katie Hockman <katie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-09-22[dev.fuzz] internal/fuzz: more fuzzing output adjustmentsKatie Hockman
This change also makes it so that non-recoverable errors (which should be pretty rare) will no longer be minimized as these failures can be flakier and harder to minimize successfully. Updates golang/go#48132 Change-Id: I991d837993ea1fb0304b3ec491cc725ef5265652 Reviewed-on: https://go-review.googlesource.com/c/go/+/351273 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>
2021-09-20[dev.fuzz] Revert "[dev.fuzz] testing: convert seed corpus values where ↵Katie Hockman
possible" This reverts commit 413c125da38990720744c0d98ab65c0d5b1602da. Reason for revert: Giving this more thought, we've decided that converting types under the hood may cause unexpected behavior to users. This is a feature that can always be added after more consideration has been done, but is not something that can be removed due to the backwards compatibility promise. Updates golang/go#45593 Change-Id: I79bab24979d7e4c294e6cb6455d4c7729d6a0efb Reviewed-on: https://go-review.googlesource.com/c/go/+/350251 Trust: Katie Hockman <katie@golang.org> Trust: Joe Tsai <joetsai@digital-static.net> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Joe Tsai <joetsai@digital-static.net>
2021-09-20[dev.fuzz] internal/fuzz: warn if fuzzing begins with empty corpusKatie Hockman
Fixes golang/go#46219 Change-Id: I7b32707d490c046d15324a3d297ec8d9f45b6e36 Reviewed-on: https://go-review.googlesource.com/c/go/+/350269 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Julie Qiu <julie@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-09-16[dev.fuzz] internal/fuzz: rework default test behavior before fuzzingKatie Hockman
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 golang/go#48327 Fixes golang/go#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>
2021-09-15[dev.fuzz] internal: fuzzing output adjustmentsKatie Hockman
Print the elapsed time as a nicely formatted duration, and make small adjustments to the command line output while fuzzing. Fixes golang/go#48132 Change-Id: Id95f84c0939171a777448c444d9b87d7af26b654 Reviewed-on: https://go-review.googlesource.com/c/go/+/349970 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>
2021-09-10[dev.fuzz] internal/fuzz: fix bug for -fuzzminimizetime of zeroKatie Hockman
Updates golang/go#48321 Change-Id: Ib35388f17580f1244a6eae4e5879f8329b6b44ce Reviewed-on: https://go-review.googlesource.com/c/go/+/349090 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-09-10[dev.fuzz] internal/fuzz: improve warning message when not instrumentedKatie Hockman
Change-Id: I005f66c965014b699de7e22750f417b28a32c03f Reviewed-on: https://go-review.googlesource.com/c/go/+/349052 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>
2021-09-08[dev.fuzz] internal/fuzz: fix panic when marshaling dataKatie Hockman
The coordinator needs to marshal data that was provided via f.Add. However, it was also attempting to marshal data that was in testdata, which was not needed, and was causing a panic. This change fixes this. Fixes golang/go#48228 Change-Id: I1256c5a287b5a09d2f8cca59beb0f0fc06cc3554 Reviewed-on: https://go-review.googlesource.com/c/go/+/348381 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-09-03[dev.fuzz] internal/fuzz: maintain debug info during minimizationRoland Shoemaker
Change-Id: I70c0229e43dfe37f70b9c79c2e6fe88d7b8d7bd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/347231 Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-09-02[dev.fuzz] internal/fuzz: don't store corpus in memoryRoland Shoemaker
Instead of holding all corpus data/values in memory, only store seed inputs added via F.Add in memory, and only load corpus entries which are written to disk when we need them. This should significantly reduce the memory required by the coordinator process. Additionally only load the corpus in the coordinator process, since the worker has no need for it. Fixes #46669. Change-Id: Ic3b0c5e929fdb3e2877b963e6b0fa14e140c1e1d Reviewed-on: https://go-review.googlesource.com/c/go/+/345096 Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-09-02[dev.fuzz] internal/fuzz: minimize inputs that expand coverageJay Conrod
When a fuzz worker discovers an input that activates coverage counters that weren't previously activated, it sends that input back to the coordinator, as before. If the coordinator also finds that input provides new coverage (that is, some other input hasn't won the race), the coordinator now sends the input back to workers for minimization. The minimization procedure now supports minimizing these interesting inputs. It attempts to find smaller inputs that preserve at least one new coverage bit. If minimization succeeds, the coordinator adds the smaller input to the corpus instead of the original. If minimization fails, the coordinator adds the original input. If minimization finds that the original input didn't provide new coverage after all (for example, a counter was activated by an unrelated background goroutine and was considered flaky), the input is ignored and not recorded. Change-Id: I81d98d6ec28abb0ac2a476f73480ceeaff674c08 Reviewed-on: https://go-review.googlesource.com/c/go/+/342997 Trust: Jay Conrod <jayconrod@google.com> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
2021-08-31[dev.fuzz] internal/fuzz: ensure crash is written if minimization interruptedJay Conrod
If any error occurs when minimizing a crash, for example, the user presses ^C because minimization is taking too long, the coordinator will now write the unminimized crash to testdata. Change-Id: I0c754125781eb184846e496c728e0505a28639d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/342995 Trust: Jay Conrod <jayconrod@google.com> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
2021-08-31[dev.fuzz] internal/fuzz: count -fuzzminimizetime toward -fuzztimeJay Conrod
Previously, when -fuzztime was given a number of executions like -fuzztime=100x, this was a count for each minimization independent of -fuzztime. Since there is no bound on the number of minimizations, this was not a meaningful limit. With this change, executions of the fuzz function during minimization count toward the -fuzztime global limit. Executions are further limited by -fuzzminimizetime. This change also counts executions during the coverage-only run and reports errors for those executions. There is no change when -fuzztime specifies a duration or when -fuzztime is not set. Change-Id: Ibcf1b1982f28b28f6625283aa03ce66d4de0a26d Reviewed-on: https://go-review.googlesource.com/c/go/+/342994 Trust: Jay Conrod <jayconrod@google.com> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
2021-08-23[dev.fuzz] internal/fuzz: coarsen each coverage counter when taking a snapshotJay Conrod
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>
2021-07-19[dev.fuzz] internal/fuzz: add more benchmarks for workersJay Conrod
* Benchmark{Marshal,Unmarshal}CorpusFile - measures time it takes to serialize and deserialize byte slices of various lengths. * BenchmarkWorkerPing - spins up a worker and measures time it takes to ping it N times as a rough measure of RPC latency. * BenchmarkWorkerFuzz - spins up a worker and measures time it takes to mutate an input and call a trivial fuzz function N times. Also a few small fixes to make this easier. Change-Id: Id7f2dc6c6c05005cf286f30e6cc92a54bf44fbf7 Reviewed-on: https://go-review.googlesource.com/c/go/+/333670 Trust: Jay Conrod <jayconrod@google.com> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
2021-06-15[dev.fuzz] testing: convert seed corpus values where possibleKatie Hockman
The types provided in f.Fuzz will be viewed as the canonical types for fuzzing. If the type is different for a seed corpus entry, then the testing package will attempt to convert it. If it can't convert it, f.Fuzz will fail. Currently, this allows converting types that may result in precision loss or a semantically different value. For example, an int(-1) can be converted to uint even though the value could be math.MaxUint64. There is a TODO to consider improving this in the future. Updates golang/go#45593 Change-Id: I2e752119662f46b68445d42b1ffa46dd30e9faea Reviewed-on: https://go-review.googlesource.com/c/go/+/325702 Trust: Katie Hockman <katie@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2021-06-08internal/fuzz: use consistent log formatRoland Shoemaker
Match the existing "fuzzing, ..." logging style for debug logs, so that processing everything is considerably simpler. Change-Id: I4da4071700b3d9f8fb1ebf0c2de91ac693fd492f Reviewed-on: https://go-review.googlesource.com/c/go/+/325876 Reviewed-by: Katie Hockman <katie@golang.org> Trust: Katie Hockman <katie@golang.org> Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-06-07[dev.fuzz] internal/fuzz: add additional debug loggingRoland Shoemaker
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>
2021-06-02[dev.fuzz] internal/fuzz: notify coordinator for minimizationJay Conrod
When a worker process finds a crasher, it now sends that result directly to the coordinator without attempting to minimize it first. The coordinator stops sending new inputs and sends the unminimized crasher back to a worker (any worker) for minimization. This prevents wasted work during minimization and will help us implement -keepfuzzing later on. We may also be able to minimize interesting inputs with this approach later. Since panics are recoverable errors (they don't terminate worker processes), we no longer attempt to minimize non-recoverable errors. This didn't work too well before: we lost too much state. Change-Id: Id142c7e91a33f64584170b0d42d22cb1f22a92d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/321835 Trust: Jay Conrod <jayconrod@google.com> Trust: Katie Hockman <katie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
2021-05-26Revert "[dev.fuzz] internal/fuzz: include coverage in logged stats"Katie Hockman
This reverts commit 54f067812dd870c305daabd22ca190b0f48e672e. Reason for revert: While this is helpful for the engineering team when we're debugging, it might lead to users feeling like the fuzzer is stuck and that there are a lot of edges that are still yet to be reached. In reality, it's very likely that the compiler will instrument more lines of code than are actually reachable by the fuzz target, so showing the ratio between number of edges hit vs. all edges can be misleading. In the future, we may want to consider making this information viewable by a debug flag or something similar. Change-Id: Ied696f8bf644445bad22c872b64daa7add605ac6 Reviewed-on: https://go-review.googlesource.com/c/go/+/322632 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>
2021-05-19[dev.fuzz] internal/fuzz: make minimization tests more reliableJay Conrod
* Introduced -fuzzminimizetime flag to control the number of time or the number of calls to spend minimizing. Defaults to 60s. Only works for unrecoverable crashes for now. * Moved the count (used by -fuzztime=1000x) into shared memory. Calling workerClient.fuzz resets it, but it will remain after the worker processes crashes. workerClient.minimize resets it once before restarting the worker the first time, but the total number of runs should still be limited during minimization, even after multiple terminations and restarts. * Renamed fuzzArgs.Count to Limit to avoid confusion. * Several other small fixes and refactorings. Change-Id: I03faa4c94405041f6dfe48568e5ead502f8dbbd2 Reviewed-on: https://go-review.googlesource.com/c/go/+/320171 Trust: Jay Conrod <jayconrod@google.com> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Katie Hockman <katie@golang.org>
2021-05-19[dev.fuzz] internal/fuzz: move coverage capture closer to functionRoland Shoemaker
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>