cmd/{go,cover}: errors on 'go test -covermode=atomic sync/atomic' #57445
Description
What version of Go are you using (go version)?
$ go version go version devel go1.20-fadd77c05b Wed Dec 21 20:18:10 2022 +0000 linux/amd64
Does this issue reproduce with the latest release?
Yes. In fact it seems to go back quite a ways (I tried with older releases back to 1.8, which also seems to have this problem, then eventually gave up).
What operating system and processor architecture are you using (go env)?
linux/amd64
What did you do?
$ GOMAXPROCS=1 go test -covermode=atomic sync/atomic
What did you expect to see?
Either a test run or an error of some sort.
What did you see instead?
Go command crashes after running out of stack space, e.g.
runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc024e80388 stack=[0xc024e80000, 0xc044e80000]
fatal error: stack overflow
...
cmd/go/internal/work.(*Builder).NewObjdir(0xc0001cedc0)
/ssd2/xgo/src/cmd/go/internal/work/action.go:373 +0x65 fp=0xc024e806f0 sp=0xc024e80688 pc=0x8c12e5
cmd/go/internal/work.(*Builder).CompileAction.func1()
/ssd2/xgo/src/cmd/go/internal/work/action.go:454 +0x46 fp=0xc024e80788 sp=0xc024e806f0 pc=0x8c1dc6
cmd/go/internal/work.(*Builder).cacheAction(0xc0001cedc0, {0xa39c79, 0x5}, 0xc000230580, 0xc024e80808)
/ssd2/xgo/src/cmd/go/internal/work/action.go:416 +0x79 fp=0xc024e807d0 sp=0xc024e80788 pc=0x8c1a19
cmd/go/internal/work.(*Builder).CompileAction(0xc0001cedc0, 0x0?, 0xc024e808b8?, 0x451dc6?)
/ssd2/xgo/src/cmd/go/internal/work/action.go:449 +0x95 fp=0xc024e80838 sp=0xc024e807d0 pc=0x8c1bf5
cmd/go/internal/work.(*Builder).CompileAction.func1()
/ssd2/xgo/src/cmd/go/internal/work/action.go:459 +0x15a fp=0xc024e808d0 sp=0xc024e80838 pc=0x8c1eda
cmd/go/internal/work.(*Builder).cacheAction(0xc0001cedc0, {0xa39c79, 0x5}, 0xc000230580, 0xc024e80950)
/ssd2/xgo/src/cmd/go/internal/work/action.go:416 +0x79 fp=0xc024e80918 sp=0xc024e808d0 pc=0x8c1a19
cmd/go/internal/work.(*Builder).CompileAction(0xc0001cedc0, 0x0?, 0xc024e80a00?, 0x451dc6?)
/ssd2/xgo/src/cmd/go/internal/work/action.go:449 +0x95 fp=0xc024e80980 sp=0xc024e80918 pc=0x8c1bf5
cmd/go/internal/work.(*Builder).CompileAction.func1()
/ssd2/xgo/src/cmd/go/internal/work/action.go:459 +0x15a fp=0xc024e80a18 sp=0xc024e80980 pc=0x8c1eda
cmd/go/internal/work.(*Builder).cacheAction(0xc0001cedc0, {0xa39c79, 0x5}, 0xc000230580, 0xc024e80a98)
/ssd2/xgo/src/cmd/go/internal/work/action.go:416 +0x79 fp=0xc024e80a60 sp=0xc024e80a18 pc=0x8c1a19
cmd/go/internal/work.(*Builder).CompileAction(0xc0001cedc0, 0x0?, 0xc024e80b48?, 0x451dc6?)
/ssd2/xgo/src/cmd/go/internal/work/action.go:449 +0x95 fp=0xc024e80ac8 sp=0xc024e80a60 pc=0x8c1bf5
...
Similar deal with 1.19. For much older releases it appears we get into some sort of infinite loop? Not sure exactly (but not sure it matters either). It seems likely that we're trying to build a version of sync/atomic that imports itself.
Looking at the code in cmd/go, it is clear that there is code that tries to prevent this scenario, but I think what's going on here is that the existing code is focused too much on the case where sync/atomic is added in as a dependency, as opposed to being the thing called out on the command line as the test target.