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
cmd/go: go clean --fuzzcache
failure in TestScript/test_fuzz_limit_dup_entry
#59062
Labels
FrozenDueToAge
GoCommand
cmd/go
NeedsFix
The path to resolution is known, but the work has not been done.
Testing
An issue that has been verified to require only test changes, not just a test failure.
Milestone
Comments
bcmills
added
Testing
An issue that has been verified to require only test changes, not just a test failure.
NeedsFix
The path to resolution is known, but the work has not been done.
GoCommand
cmd/go
labels
Mar 15, 2023
Found new dashboard test flakes for:
2023-03-14 21:49 windows-amd64-longtest go@ebf8e26d cmd/go.TestScript (log)
|
Change https://go.dev/cl/476755 mentions this issue: |
Change https://go.dev/cl/476815 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Mar 16, 2023
The fuzzing cache for interesting inputs is shared across all invocations of scripts by default. When 'go clean -fuzzcache' is called, or fuzz targets in different scripts have the same names, we can get race-y unexpected behavior. Since there isn't a easy way to set just the fuzz cache directory (test has the flag -test.fuzzcachedir, but it requires setting it on each call to 'go test'), instead we just consistently set GOCACHE to point to a directory in the WORK dir. As a byproduct this also prevents usage of a shared build cache, so we see an increase in build time for these tests. Updates #59062 Change-Id: Ie78f2943b94f3302c5bdf1f8a1e93b207853666a Reviewed-on: https://go-review.googlesource.com/c/go/+/476755 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
gopherbot
pushed a commit
that referenced
this issue
Mar 16, 2023
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>
@rolandshoemaker, was this fixed by CL 476815? |
It seems so 🎉. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
FrozenDueToAge
GoCommand
cmd/go
NeedsFix
The path to resolution is known, but the work has not been done.
Testing
An issue that has been verified to require only test changes, not just a test failure.
Pulled out from #55311 (comment).
I think the fix is to set
env GOCACHE=$WORK/cache
or similar explicitly in script tests that need a clean fuzzcache.The text was updated successfully, but these errors were encountered: