runtime/coverage: counter mode clash when testing with instrumented go tools #57924
Description
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.