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
Closed

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

danderson opened this issue Nov 30, 2017 · 14 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@danderson
Copy link
Contributor

danderson 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 added NeedsFix The path to resolution is known, but the work has not been done. release-blocker labels 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
Copy link
Contributor

/cc @thanm

danderson added a commit to metallb/metallb that referenced this issue Nov 30, 2017
@bradfitz
Copy link
Contributor

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

@danderson
Copy link
Contributor Author

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

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

@bradfitz
Copy link
Contributor

I can reproduce the crash at tip.

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

@danderson
Copy link
Contributor Author

As predicted, you beat me to it :)

@bradfitz
Copy link
Contributor

Yup, this crash begins at 4435fcf.

All yours, @thanm! :)

@thanm
Copy link
Contributor

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

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

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

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

@cherrymui
Copy link
Member

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

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

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

@golang golang locked and limited conversation to collaborators Dec 1, 2018
@rsc rsc unassigned thanm Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants