aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/internal/sys
diff options
context:
space:
mode:
authorKatie Hockman <katie@golang.org>2021-10-22 15:59:15 -0400
committerKatie Hockman <katie@golang.org>2021-10-27 19:18:20 +0000
commit514ebaec358488d1dcf7253b9d05b4ad8c76c390 (patch)
treecf278164ff27016f8055cf992af2cb88117cde53 /src/cmd/internal/sys
parent259735f97a2dfd33849eacef15047f5a0964498e (diff)
downloadgo-514ebaec358488d1dcf7253b9d05b4ad8c76c390.tar.xz
internal/fuzz: don't deflake coverage found while fuzzing
Previously, the worker would attempt to deflake an input that was reported to have caused new coverage. The chances of a flake causing new coverage seem pretty low to me, and even if it was a flake that caused it, adding that input to the cache doesn't seem like a bad thing. The input is already going to be deflaked during minimization anyway. If by some off-chance the code is causing a lot of flaky coverage increases, and the user doesn't want minimization to occur, then setting -fuzzminimizetime=1x will deflake in the way they want without minimizing. This can be documented as needed. This fixes a bug where the mem.header().count could have been one too large if an unrecoverable crash occured while deflaking an input that caused code coverage. Fixes #49047 Change-Id: Ibdf893d7a89a46dd700702afb09e35623615390e Reviewed-on: https://go-review.googlesource.com/c/go/+/358094 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: Roland Shoemaker <roland@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Diffstat (limited to 'src/cmd/internal/sys')
0 files changed, 0 insertions, 0 deletions