Repository navigation
testing,internal/fuzz: Fuzzer reports 0 execs/sec and keeps running #51484
Copy link
Copy link
Closed
Labels
FrozenDueToAgeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.fuzzIssues related to native fuzzing supportIssues related to native fuzzing support
Milestone
Description
#!watchflakes
post <- pkg == "cmd/go" && `fuzz: elapsed: \d+m\d+s, execs: \d+ \(0/sec\),` && (date < "2023-10-01" || builder ~ `^go1.20`)
What version of Go are you using (go version)?
$ go version go version go1.18rc1 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/capnspacehook/.cache/go-build" GOENV="/home/capnspacehook/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/capnspacehook/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/capnspacehook/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/capnspacehook/sdk/go1.18rc1" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/capnspacehook/sdk/go1.18rc1/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.18rc1" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="0" GOMOD="/home/capnspacehook/Documents/git/egress-eddie/go.mod" GOWORK="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1895014098=/tmp/go-build -gno-record-gcc-switches"
What did you do?
- Clone https://github.com/capnspacehook/toml
- Switch to the
invalid_utf8branch - Clone https://github.com/capnspacehook/egress-eddie
- Switch to the
go_fuzzer_bugbranch - Replace your local fuzz cache with the contents of
fuzzcache - Add a
replacedirective to thego.modfile replacinggithub.com/BurntSushi/tomlwith where you clonedgithub.com/capnspacehook/toml - Start fuzzing:
go test -run Parse -fuzz Fuzz
What did you expect to see?
The fuzzer trying many inputs per second
What did you see instead?
fuzz: elapsed: 0s, gathering baseline coverage: 0/253 completed
fuzz: elapsed: 1s, gathering baseline coverage: 253/253 completed, now fuzzing with 12 workers
fuzz: elapsed: 3s, execs: 42532 (14175/sec), new interesting: 14 (total: 267)
fuzz: elapsed: 6s, execs: 78830 (12092/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 9s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 12s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 15s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 18s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 21s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 24s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 27s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
fuzz: elapsed: 30s, execs: 78830 (0/sec), new interesting: 20 (total: 273)
May be related to #48591.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
FrozenDueToAgeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.fuzzIssues related to native fuzzing supportIssues related to native fuzzing support
Type
Projects
- StatusShow more project fieldsDone
- StatusShow more project fieldsDone
- StatusShow more project fieldsDone
Activity
bcmills commentedon Mar 4, 2022
(CC @rolandshoemaker)
joewreschnig commentedon Mar 23, 2022
I've also noticed this in one test; after running with 0/sec for a while (but clearly not actually 0, given my computer's CPU usage) it came back with an unusually, almost implausibly, high number of execs/sec for a few runs before returning to normal:
ianlancetaylor commentedon Jun 24, 2022
CC @golang/fuzzing
What is the current status here? This issue is currently in the 1.19 milestone. Should it move to 1.20? To Backlog? Thanks.
capnspacehook commentedon Nov 2, 2022
I can still easily reproduce this in github actions, it doesn't seem to be as specific as I thought: https://github.com/capnspacehook/egress-eddie/actions/runs/3374243584/jobs/5599662068
bcmills commentedon Nov 21, 2022
There is at least one instance of this in the Go build dashboard as well:
https://build.golang.org/log/99d38c470b4df7a559bb833dc8f1fd15bf8d1aa3
mdempsky commentedon Nov 22, 2022
I'm seeing this happen too (i.e., 10-30 second stretches of 0 execs/sec reported). I've instrumented my fuzz target to call T.Fatal if it takes longer than 1 second to finish, and it doesn't seem to trigger at all. So I'm guessing it's just a UI issue, and that the fuzzer is actually steadily working the whole time still.
28 remaining items
internal/fuzz: release lock when reading file fails
rolandshoemaker commentedon Apr 19, 2023
@bcmills I think we might've also squashed this 🎉.
gopherbot commentedon Sep 8, 2023
Found new dashboard test flakes for:
2023-09-06 14:22 linux-amd64-longtest go@023b542e cmd/go.TestScript (log)
— watchflakes
bcmills commentedon Sep 8, 2023
Commit 023b542 is on
release-branch.go1.20(#59483).gopherbot commentedon Feb 5, 2024
Found new dashboard test flakes for:
2024-01-31 17:29 go1.20-linux-amd64-longtest release-branch.go1.20@746a0727 cmd/go.TestScript/test_fuzz_mutator (log)
— watchflakes