cmd/link: panic: runtime error: slice bounds out of range

[kaoet]

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

1.9.4

Does this issue reproduce with the latest release?

Yes

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

Ubuntu 17.10 linux_amd64

What did you do?

I'm compiling my project with bazel by just running bazel build node/agent/unsullied.

The code is too complicated. I'm working to make a minimum example.

What did you expect to see?

bazel build succeed.

What did you see instead?

At the last step, GoLink crashed.

ERROR: /src/node/agent/unsullied/BUILD.bazel:42:1: GoLink node/agent/unsullied/linux_amd64_stripped/unsullied failed (Exit 1)
github.com/vishvananda/netlink.NewHandleAt: call to external function
github.com/vishvananda/netlink.(*Handle).LinkList: call to external function
panic: runtime error: slice bounds out of range

goroutine 1 [running]:
cmd/link/internal/ld.decodetypePtrdata(0x6f8060, 0xc42219a3d8, 0xc42082bbd0)
	/usr/local/go/src/cmd/link/internal/ld/decodesym.go:83 +0x9c
cmd/link/internal/ld.(*GCProg).AddSym(0xc426f628f0, 0xc422195c40)
	/usr/local/go/src/cmd/link/internal/ld/data.go:1260 +0x76
cmd/link/internal/ld.(*Link).dodata(0xc4204cc000)
	/usr/local/go/src/cmd/link/internal/ld/data.go:1573 +0x1932
cmd/link/internal/ld.Main()
	/usr/local/go/src/cmd/link/internal/ld/main.go:219 +0x9fd
main.main()
	/usr/local/go/src/cmd/link/main.go:58 +0xac
2018/02/08 18:05:07 error running linker: exit status 1
Target //node/agent/unsullied:unsullied failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 116.070s, Critical Path: 1.31s
FAILED: Build did NOT complete successfully

[ianlancetaylor]

We're likely to need reproduction instructions. Thanks.

[josharian]

I’m on my phone but I’m pretty sure there are several duplicates of this already, all without reproducers.

[jayconrod]

Hey @kaoet, I believe this is a duplicate of bazel-contrib/rules_go#1116, so I'll close this issue in favor of that one.

TL;DR: we believe this is due to multiple versions of the same package being included in the build. Only one will actually get linked, which means that a dependent library may be compiled against one version and linked against another.

The main way to work around this is to ensure there are no duplicate libraries unless they use importmap attribute to ensure unique names.

[josharian]

It’d be nice if cmd/link could detect this scenario somehow and issue an appropriate warning, rather than panicking, which will continue to lead to new issues being filed here. I’m not sure how or if that is possible, but reopening this issue for that. Since you understand the issue, do you by chance have a minimal reproduction?

[jayconrod]

It may be difficult for cmd/link to detect this without a change in the package format. Each .a file produced by the compiler would need to be stamped with a unique id, and it would need to include the ids of the other .a files it was compiled against. The linker would need to verify these ids.

It's the responsibility of the build system (go build or Bazel rules_go in this case) to prevent this situation from happening, so while adding verification to cmd/link would be valuable, I'm not sure it justifies the additional complexity.

go build prevents this from happening by passing -importmap or -importcfg to the compiler for vendored packages, which I think is the only case where this would come up.

rules_go should prevent this from happening by verifying that no two libraries passed to the linker have the same import path. At the moment, rules_go requires you to set importmap attributes on go_library rules manually if you need duplicate packages. That could be automated with Gazelle though.