runtime/coverage: counter mode clash when testing with instrumented go tools

[thanm]

What version of Go are you using (go version)?

$ go version
go version devel go1.20-be7781e3b8 Tue Jan 17 11:52:25 2023 -0500 linux/amd64

Does this issue reproduce with the latest release?

Requires 1.20 or later.

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

While working on a cover.bash script to collect project wide coverage data for Go's std/cmd, I ran into issues when trying to run the equivalent of "go dist test" with coverage enabled and with coverage-instrumented tools (compiler, linker, etc).

Here is a stripped down recipe of the commands being run:

go install -coverpkg=all cmd/compile
D=/tmp/covprofiles
rm -rf $D ; mkdir $D
export GOCOVERDIR=$D
go test -coverpkg=all -race -count=1 -short -run=Output runtime/race

What did you expect to see?

Expected to see a clean -cover run for runtime/race:

ok  	runtime/race	6.505s	coverage: 5.7% of statements in all

What did you see instead?

Final "go test" fails with

# error generating coverage report: internal error: counter mode clash: "atomic" from test harness,
 "set" from data file /tmp/go-build482604180/b001/gocoverdir/covmeta.0ed46d8a48b6014ba4cec613e2eee6ef

What's happening here is that the instrumented compiler is writing out coverage profiles (with mode "set") to the same location that the test is emitting atomic-mode files. This in itself is not necessarily a problem, but it appears that the test harness is picking up pods from the compiler when it is doing its reporting, which should not be happening.

[gopherbot]

Change https://go.dev/cl/462756 mentions this issue: runtime/coverage: avoid non-test coverage profiles in test report helper

[gopherbot]

Change https://go.dev/cl/463417 mentions this issue: [release-branch.go1.20] runtime/coverage: avoid non-test coverage profiles in test report helper