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

cmd/link: "panic: index out of range" on go tip linker #22941

Closed
danderson opened this issue Nov 30, 2017 · 14 comments

Comments

Projects
None yet
5 participants
@danderson
Copy link

commented Nov 30, 2017

Please answer these questions before submitting your issue. Thanks!

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

go version devel +2708da0dc1 Thu Nov 30 17:12:32 2017 +0000 linux/amd64

Does this issue reproduce with the latest release?

No, released versions are clean.

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/travis/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/travis/gopath"
GORACE=""
GOROOT="/home/travis/.gimme/versions/go"
GOTMPDIR=""
GOTOOLDIR="/home/travis/.gimme/versions/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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-build924681449=/tmp/go-build -gno-record-gcc-switches"

What did you do?

My project's test automation runs compilation and testing against go tip, to find issues early in the dev cycle. Today, it crashed: https://travis-ci.org/google/metallb/jobs/309618087#L433

# go.universe.tf/metallb/controller
panic: runtime error: index out of range
goroutine 1 [running]:
cmd/link/internal/ld.decodetypeKind(...)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/decodesym.go:69
cmd/link/internal/ld.newtype(0xc4204f8000, 0xc434039678, 0xc43424f180)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/dwarf.go:398 +0x294c
cmd/link/internal/ld.defgotype(0xc4204f8000, 0xc434039678, 0x46)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/dwarf.go:393 +0x1d5
cmd/link/internal/ld.importInfoSymbol(0xc4204f8000, 0xc4218f1200)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/dwarf.go:1071 +0x1d6
cmd/link/internal/ld.collectAbstractFunctions(0xc4204f8000, 0xc421836568, 0xc421acee00, 0xc429076800, 0xcd, 0x100, 0x56, 0xcd, 0x100)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/dwarf.go:1113 +0x30d
cmd/link/internal/ld.writelines(0xc4204f8000, 0xc420504840, 0xc43110a000, 0xd4e, 0x1000, 0xc4340368f0, 0xc4340369e8, 0xc42930c000, 0xae, 0x100, ...)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/dwarf.go:1237 +0x17e6
cmd/link/internal/ld.dwarfgeneratedebugsyms(0xc4204f8000)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/dwarf.go:1717 +0x8ee
cmd/link/internal/ld.(*Link).dodata(0xc4204f8000)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/data.go:1554 +0x3419
cmd/link/internal/ld.Main(0x6e8380, 0x10, 0x20, 0x1, 0x7, 0x10, 0x5f9480, 0x1b, 0x5f682a, 0x14, ...)
	/home/travis/.gimme/versions/go/src/cmd/link/internal/ld/main.go:220 +0xab0
main.main()
	/home/travis/.gimme/versions/go/src/cmd/link/main.go:62 +0x277

To reproduce:

  • Install Go at the given git version
  • go get go.universe.tf/metallb/controller

If that doesn't cause the crash, you may need to pull the exact vendored dependencies:

  • go get github.com/Masterminds/glide
  • cd $GOPATH/src/go.universe.tf/metallb
  • glide install
  • go install ./controller

What did you expect to see?

Program should compile happily (it does with 1.8 and 1.9)

What did you see instead?

The above crash.

@bradfitz bradfitz added this to the Go1.10 milestone Nov 30, 2017

@bradfitz bradfitz changed the title "panic: index out of range" on go tip linker cmd/link: "panic: index out of range" on go tip linker Nov 30, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

/cc @thanm

danderson added a commit to danderson/metallb that referenced this issue Nov 30, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

@danderson, any chance you could reproduce both at 4435fcf and just before 4435fcf?

@danderson

This comment has been minimized.

Copy link
Author

commented Nov 30, 2017

I don't have a local go tip installation right now - I'll get one set up and try, though y'all may beat me to it.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

No worries. I'll try to repro locally first.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

I can reproduce the crash at tip.

It works at dbb1d19 (which is the parent of 4435fcf).

@danderson

This comment has been minimized.

Copy link
Author

commented Nov 30, 2017

As predicted, you beat me to it :)

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

Yup, this crash begins at 4435fcf.

All yours, @thanm! :)

@thanm

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

I will take a look.

FWIW I've seen that assert in cases where you have a mix of Go objects (some object files bulit by previous versions of the compiler), but I'll see what I can find out.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

@thanm, such things shouldn't happen anymore with the new cmd/go content-based caching. Your change is well past the cmd/go changes.

@thanm

This comment has been minimized.

Copy link
Member

commented Nov 30, 2017

I've reproduce the issue. Still not 100% sure, but I think it has to do with an interaction between the new DWARF stuff and the linker's dead code pass (the one of the type symbols referred to by a DWARF abstract function appears to be mysteriously missing).

If this is holding anyone up, let me know and I can disable the feature with a flag flip while I work on it.

@danderson

This comment has been minimized.

Copy link
Author

commented Nov 30, 2017

FWIW, it's not blocking me, I just disabled testing on go tip in my automation until it's fixed.

@cherrymui

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2017

Smaller reproduce:

p/p.go

package p

import "q"

type T struct {
	X *q.P
}

func F(in, out *T) {
	*out = *in
	if in.X != nil {
		in, out := &in.X, &out.X
		if *in == nil {
			*out = nil
		} else {
			*out = new(q.P)
			**out = **in
		}
	}
	return
}

//go:noinline
func G(x, y *T) {
	F(x, y)
}

q/q.go

package q

type P int

main/main.go

package main

import "p"

func main() {
	p.G(nil, nil)
}

It seems that when compiling p, it generates the abstract function DIE of F with references to go.info.**q.P, for the locals in and out (in the inner scope). When the linker sees go.info.**q.P, it tries to make the type DIE from type.**q.P, which is, however, not generated by the compiler.

@cherrymui

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2017

The variables in the inner scope (in, out in F) are optimized by the compiler, so the type symbols for them are not created.

@gopherbot

This comment has been minimized.

Copy link

commented Dec 1, 2017

Change https://golang.org/cl/81415 mentions this issue: cmd/compile: fix DWARF type symbol buglet

@gopherbot gopherbot closed this in 9372166 Dec 1, 2017

@golang golang locked and limited conversation to collaborators Dec 1, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.