cmd/go: Duplicate symbols with more than one main package in -coverpkg

[imsodin]

I have been told by @bcmills in #30374 (comment) to create a new issue. This report is essentially the same as #30374 (comment):

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

$ go version
go version go1.12.5 linux/amd64

Does this issue reproduce with the latest release?

Didn't try.

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

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/simon/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/media/ext4_data/Coding/go"
GOPROXY=""
GORACE=""
GOROOT="/media/ext4_data/Linux/source/go"
GOTMPDIR=""
GOTOOLDIR="/media/ext4_data/Linux/source/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/simon/tmp/syncthing/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build248314634=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Running all tests with -coverpkg on all packages and using -coverprofile like this:

git clone https://github.com/syncthing/syncthing.git
cd syncthing
go test -short -coverprofile coverage.out -coverpkg ./cmd/...,./lib/... ./cmd/... ./lib/...

What did you expect to see?

No errors.

What did you see instead?

Errors like previously reported in the linked issue:

2019/05/15 16:02:50 duplicate symbol go.constinfo.main (types 45 and 45) in github.com/syncthing/syncthing/cmd/strelaypoolsrv and /home/simon/.cache/go-build/87/87afda35dba0b8de44e2f9d449eda7ce4caef7ed781612883b4e457eab1ee3d5-d(_go_.o)

The same also happens with just ./.... I cleaned out ~/.cache/go-build for good measure, didn't change anything.

To make sure it isn't some weird local problem of mine I also ran it on Syncthing's CI and reproduced the issue there as well: https://build.syncthing.net/viewLog.html?buildId=39242&buildTypeId=Syncthing_Coverage&tab=buildLog

[bcmills]

CC @jayconrod

[imsodin]

Actually -coverprofile has nothing to do with it, the error is the same regardless of whether that flag is used or not. I don't understand how my issue is different from #30374 (@bcmills).

[jayconrod]

@imsodin I was able to reproduce this with 1.12.5 but not with tip. I believe this was fixed in CL 176558 as a fix for #31946. That's a slightly different bug from #30374. I didn't realize it affected 1.12.

I'll need to verify 176558 would actually fix this on 1.12.5. If it does, I'll backport to 1.12. If not, I'll investigate this as a new issue. I'm at a conference right now, so it may take a few days though.

[jayconrod]

@imsodin Thanks for reporting this, both here and in #30374. I've confirmed that https://golang.org/cl/176558 fixes the issue when cherry-picked onto 1.12.5.

#32295 will track the cherry-pick onto 1.12.

[gopherbot]

Change https://golang.org/cl/179677 mentions this issue: [release-branch.go1.12] cmd/go: force -coverpkg main packages to be built as libraries

[andreasph]

experimenting this issue on circleci with 1.11.5 and 1.11.12 (not on 1.12.7):

GO111MODULE=on TZ= go test -race -p 1 -tags "system" \
		-coverprofile=%REDACTED%/st_coverage.txt -covermode=atomic -coverpkg=%REDACTED%/... ./...

2019/08/01 12:18:43 duplicate symbol go.constinfo.main (types 44 and 44) in  .%REDACTED%/cmd/a-main-package and $WORK/b423/_pkg_.a(_go_.o)

strangely enough it happened after adding a new main package, but we still had multiple ones before and never encountered the issue.

I'm not sure if 1.11 was also affected and the fix was never backported to 1.11 or it is something else,

do I have to open a new ticket?

[bcmills]

@andreasph, the fix was not (and is not planned to be) backported to 1.11. The workaround, if needed, is to upgrade to the latest patch release of 1.12, or wait for 1.13 (scheduled to go out soon) and upgrade to that.

[andreasph]

@bcmills fair enough, we will bump to 1.12.7. just one curiosity: is it somehow a floating behaviour in the affected versions? because we already had multiple main packages but the bug emerged only after adding a new one

[jayconrod]

@andreasph This was a subtle bug that had to be fixed and reopened a couple times as more cases were discovered. I believe there were cases where multiple main packages didn't trigger the bug. In any case, all the fixes were backported to 1.12, so it should be resolved there.

[caarlos0]

still happens on 1.13.1 when running:

go test ./... -v -failfast -race -coverpkg=./... -covermode=atomic -coverprofile=coverage.txt

Changing to go test ./pkg/... etc prevents the issue.

Removing the coverpkg flag also prevents the issue.

Maybe this should be reopen?

[bcmills]

@caarlos0, the fix in 1.13 turned out to be incomplete (didn't cover GOPATH mode, which had unexpectedly regressed); see #34223 (comment).

The fix for GOPATH mode is slated to go out in 1.13.2. In the meantime, please try golang.org/dl/gotip or a build from source on release-branch.go1.13 and let us know if it still isn't fixed for your usage.

[caarlos0]

@bcmills worked fine on 0000f0b!

Thanks!