Skip to content
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

Jump to bottom

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

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

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

kaoet opened this issue Feb 8, 2018 · 5 comments
Labels
help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@kaoet
Copy link

kaoet commented Feb 8, 2018 •
edited

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 cmd/link panic: runtime error: slice bounds out of range cmd/link: panic: runtime error: slice bounds out of range Feb 8, 2018
@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 8, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Feb 8, 2018
@ianlancetaylor
Copy link
Contributor

We're likely to need reproduction instructions. Thanks.

@ianlancetaylor ianlancetaylor added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Feb 8, 2018
@josharian
Copy link
Contributor

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

@jayconrod
Copy link
Contributor

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.

@josharian
Copy link
Contributor

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
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. release-blocker labels Jun 23, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Unplanned Jun 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@josharian @jayconrod @kaoet @ianlancetaylor @ALTree