-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testing,internal/fuzz: Fuzzer reports 0 execs/sec and keeps running #51484
Comments
(CC @rolandshoemaker) |
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:
|
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. |
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 |
There is at least one instance of this in the Go build dashboard as well: |
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. |
@mdempsky, I don't think it's just a UI issue, or the |
Found new dashboard test flakes for:
2022-11-19 16:50 windows-amd64-longtest go@58a2db18 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2022-11-17 13:46 windows-amd64-longtest go@bed970b3 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-01-20 17:47 linux-arm64-longtest go@09d852ce cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-01-25 19:53 windows-amd64-longtest go@b68d699a cmd/go.TestScript (log)
2023-01-26 00:52 linux-amd64-longtest go@45110692 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-02-09 18:01 linux-amd64-longtest-race go@9987cb6c cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-02-10 14:49 windows-amd64-longtest go@c3d3be10 cmd/go.TestScript (log)
2023-02-17 21:23 linux-amd64-longtest go@209df389 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-03-01 21:23 windows-amd64-longtest go@c10ba768 cmd/go.TestScript (log)
2023-03-02 15:57 linux-amd64-longtest go@b958d4a5 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-03-09 19:19 linux-amd64-longtest go@642542cb cmd/go.TestScript (log)
|
Change https://go.dev/cl/475196 mentions this issue: |
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>
Found new dashboard test flakes for:
2023-03-10 17:18 linux-amd64-longtest-race go@f52bede3 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-03-10 17:59 linux-arm64-longtest go@3790ceca cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-03-13 17:03 linux-amd64-longtest go@e671fe0c cmd/go.TestScript (log)
|
Looks like we switched from |
Found new dashboard test flakes for:
2023-03-13 20:25 linux-amd64-longtest-race go@82c713fe cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-03-14 09:07 linux-amd64-longtest-race go@a54fe8a2 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-03-15 07:15 linux-amd64-longtest-race go@574c6209 cmd/go.TestScript (log)
|
Change https://go.dev/cl/476595 mentions this issue: |
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>
Found new dashboard test flakes for:
2023-03-15 21:08 linux-amd64-longtest go@3128edfe cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-03-15 21:24 linux-arm64-longtest go@617cf132 cmd/go.TestScript (log)
|
Change https://go.dev/cl/476815 mentions this issue: |
Found new dashboard test flakes for:
2023-03-16 05:12 linux-amd64-longtest-race go@c69ff3a7 cmd/go.TestScript (log)
|
When corpusEntryData failed in workerClient.fuzz and workerClient.minimize, the shared memory mutex wasn't properly given up, which would cause a deadlock when worker.cleanup was called. This was tickled by #59062, wherein the fuzz cache directory would be removed during operation of the fuzzer, causing corpusEntryData to fail because the entry files no longer existed. Updates #51484 Change-Id: Iea284041c20d1581c662bddbbc7e12191771a364 Reviewed-on: https://go-review.googlesource.com/c/go/+/476815 Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
@bcmills I think we might've also squashed this 🎉. |
Found new dashboard test flakes for:
2023-09-06 14:22 linux-amd64-longtest go@023b542e cmd/go.TestScript (log)
|
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)
|
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
invalid_utf8
branchgo_fuzzer_bug
branchfuzzcache
replace
directive to thego.mod
file replacinggithub.com/BurntSushi/toml
with where you clonedgithub.com/capnspacehook/toml
go test -run Parse -fuzz Fuzz
What did you expect to see?
The fuzzer trying many inputs per second
What did you see instead?
May be related to #48591.
The text was updated successfully, but these errors were encountered: