New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kaoet opened this Issue Feb 8, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@kaoet

kaoet commented Feb 8, 2018

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

@ALTree ALTree changed the title from cmd/link panic: runtime error: slice bounds out of range to cmd/link: panic: runtime error: slice bounds out of range Feb 8, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Feb 8, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Feb 8, 2018

We're likely to need reproduction instructions. Thanks.

@josharian

This comment has been minimized.

Contributor

josharian commented Feb 8, 2018

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

@jayconrod

This comment has been minimized.

Contributor

jayconrod commented Feb 8, 2018

Hey @kaoet, I believe this is a duplicate of bazelbuild/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.

@jayconrod jayconrod closed this Feb 8, 2018

@josharian

This comment has been minimized.

Contributor

josharian commented Feb 8, 2018

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?

@josharian josharian reopened this Feb 8, 2018

@jayconrod

This comment has been minimized.

Contributor

jayconrod commented Feb 8, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment