cmd/go,os: build cache checksum errors in x/tools/cmd/callgraph.TestCallgraph on windows/arm64

[bcmills]

--- FAIL: TestCallgraph (11.99s)
    main_test.go:85: err: exit status 1: stderr: go build pkg: loading compiled Go files from cache: reading srcfiles list: cache entry not found: bad checksum
        
    main_test.go:100: got:
         <root> --> pkg.init
        pkg.main2 --> (pkg.D).f
        pkg.main --> pkg.main2
        pkg.main --> (pkg.C).f
        <root> --> pkg.main
        
    main_test.go:100: got:
         (*os.File).setDeadline --> (*os.File).checkValid
        (time.Time).IsZero --> (*time.Time).sec
        (time.Time).IsZero --> (*time.Time).nsec
        internal/poll.setDeadlineImpl --> (time.Time).IsZero
…
FAIL
FAIL	golang.org/x/tools/cmd/callgraph	12.869s

greplogs --dashboard -md -l -e 'reading srcfiles list: cache entry not found: bad checksum' --since=2021-01-01

2022-01-19T20:29:36-7c251d6-9de1ac6/windows-arm64-10
2021-11-02T15:54:27-058ed05-c3cb1ec/windows-arm64-10
2021-11-01T13:50:47-513e3fb-4a84298/windows-arm64-10
2021-10-14T17:38:39-e69ba9d-011fd00/windows-arm64-10
2021-09-14T02:53:17-384e5da-ee91bb8/windows-arm64-10

[bcmills]

The loading compiled Go files from cache error string is a hapax legomenon in the Go project; it definitely comes from here, in cmd/go/internal/work:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/exec.go;l=739;drc=2580d0e08d5e9f979b943758d3c49877fb2324cb
The reading srcfiles list comes from here:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/exec.go;l=1006;drc=master

The error appears to indicate file corruption in the cmd/go build cache, but I don't have any theories as to how that corruption is occurring or why it seems to only affect this one test on this one builder, and the test understandably doesn't provide much detail on the sequence or timing of the go invocations it is running.

Given the failure mode, I think the bug is more likely in os, syscall, or cmd/go itself than in x/tools/cmd/callgraph. windows/arm64 is not a first-class port and lacks a longtest builder, so it may be that x/tools/cmd/callgraph is incidentally triggering an underlying bug in an interaction that is being skipped (or isn't covered at all) in the os and/or cmd/go tests.

We are also running a relatively old Windows 10 build (#48946, CC @golang/release, @zx2c4), so I can't rule out a bug in the underlying platform either.

[bcmills]

This is a release-blocker via #11811, but given that this is not a first-class port and appears to be a platform-specific bug affecting only one test, I plan to add a test skip for this specific builder in x/tools/cmd/callgraph.TestCallgraph and then move this issue to the Backlog without investigating further.

If we also observe this failure mode on the new windows-arm64-11 builder once that is up and running, and/or if we upgrade windows/arm64 to a first-class port, we can reprioritize an investigation.

[gopherbot]

Change https://golang.org/cl/379734 mentions this issue: cmd/callgraph: skip TestCallgraph on the windows-arm64-10 builder

[rsc]

The 'bad checksum' means we read a file that was named for a sha256 hash and the content did not match that sha256.

[rsc]

The fact that this is only windows/arm64 and that we've seen absolutely no mentions of it on other systems or in other bug reports makes me feel okay with this not being a release-blocker. If there really is corruption, the content-addressed and checksum-checked nature of the cache means that the system is either failstop or works correctly. So far we are getting no reports of failstop other than this one.

[bcmills]

I agree, but the failure rate for TestCallgraph is high enough that I think we should at least add that skip in the interim to avoid masking other failures on the builders.