Ask questionscmd/objdump: panic: runtime error: index out of range [1048574] when disassembling empty infinite loop

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: -->

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

<pre> macos: $ go version go version go1.13.6 darwin/amd64


go version

go version go1.13.6 linux/amd64


Does this issue reproduce with the latest release?

yes, so far go1.13.6 is the latest release.

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

<details><summary><code>go env</code> Output</summary><br><pre> macos: $ go env GO111MODULE="on" GOARCH="amd64" GOBIN="" GOCACHE="/Users/tonybai/Library/Caches/go-build" GOENV="/Users/tonybai/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/tonybai/Go" GOPRIVATE="" GOPROXY=",direct" GOROOT="/Users/tonybai/.bin/go1.13.6" GOSUMDB="off" GOTMPDIR="" GOTOOLDIR="/Users/tonybai/.bin/go1.13.6/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/cz/sbj5kg2d3m3c6j650z0qfm800000gn/T/go-build651515497=/tmp/go-build -gno-record-gcc-switches -fno-common"


go env

GO111MODULE="on" GOARCH="amd64" GOBIN="/root/.bin/go1.13.6/bin" GOCACHE="/root/.cache/go-build" GOENV="/root/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/root/go" GOPRIVATE="" GOPROXY=",direct" GOROOT="/root/.bin/go1.13.6" GOSUMDB="" GOTMPDIR="" GOTOOLDIR="/root/.bin/go1.13.6/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/dev/null" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build943673068=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on is best. -->

I have a go source file:

<pre> $ cat go-scheduler-model-case3.go package main

import ( "fmt" "runtime" "time" )

func add(a, b int) int { return a + b }

func deadloop() { for { add(3, 5) } }

func main() { runtime.GOMAXPROCS(1) go deadloop() for { time.Sleep(time.Second * 1) fmt.Println("I got scheduled!") } } </pre>

I ran the commands below and got a panic:

<pre> on macos: $go build -o go-scheduler-model-case3 go-scheduler-model-case3.go $ go tool objdump -S go-scheduler-model-case3 > go-scheduler-model-case3.s panic: runtime error: index out of range [1048574] with length 27

goroutine 1 [running]: cmd/internal/objfile.(*FileCache).Line(0xc0004cdd18, 0xc0001561b0, 0x82, 0xfffff, 0x10da0e1, 0xc0004cdae0, 0xc00007263d, 0x1099780, 0x1099781) /usr/local/go/src/cmd/internal/objfile/disasm.go:178 +0x600 cmd/internal/objfile.(*Disasm).Print.func1(0x1099781, 0x2, 0xc0001561b0, 0x82, 0xfffff, 0xc0001a9fa0, 0x15) /usr/local/go/src/cmd/internal/objfile/disasm.go:232 +0xd8 cmd/internal/objfile.(*Disasm).Decode(0xc00049e000, 0x1099780, 0x1099790, 0x0, 0x0, 0x0, 0xc0004cdde8) /usr/local/go/src/cmd/internal/objfile/disasm.go:283 +0x279 cmd/internal/objfile.(*Disasm).Print(0xc00049e000, 0x11f6e00, 0xc000094008, 0x0, 0x1001000, 0xffffffffffffffff, 0x1) /usr/local/go/src/cmd/internal/objfile/disasm.go:227 +0x4e1 main.main() /usr/local/go/src/cmd/objdump/main.go:90 +0x61d

on linux: go tool objdump -S ./ go-scheduler-model-case3> go-scheduler-model-case3.s panic: runtime error: index out of range [1048574] with length 27

goroutine 1 [running]: cmd/internal/objfile.(*FileCache).Line(0xc0003d5d18, 0xc000152b60, 0x16, 0xfffff, 0x4d7601, 0xc0003d5ae0, 0xc000069c45, 0x48d150, 0x48d151) /usr/local/go/src/cmd/internal/objfile/disasm.go:178 +0x600 cmd/internal/objfile.(*Disasm).Print.func1(0x48d151, 0x2, 0xc000152b60, 0x16, 0xfffff, 0xc0004960a0, 0x15) /usr/local/go/src/cmd/internal/objfile/disasm.go:232 +0xd8 cmd/internal/objfile.(*Disasm).Decode(0xc00007ed00, 0x48d150, 0x48d153, 0x0, 0x0, 0x0, 0xc0003d5de8) /usr/local/go/src/cmd/internal/objfile/disasm.go:283 +0x279 cmd/internal/objfile.(*Disasm).Print(0xc00007ed00, 0x5f4460, 0xc00000e020, 0x0, 0x401000, 0xffffffffffffffff, 0x1) /usr/local/go/src/cmd/internal/objfile/disasm.go:227 +0x4e1 main.main() /usr/local/go/src/cmd/objdump/main.go:90 +0x61d


What did you expect to see?

go tool objdump -S go-scheduler-model-case3 > go-scheduler-model-case3.s run ok

What did you see instead?

the panic information listed above.


Answer questions dr2chase

Problem with the infinite loop answer is that (1) we're not super excited about large changes right now and (2) I am not exactly sure it will work anyway for the debugger. I just tried "debugging"

package main

func call() {

func main() {
	for { call(); }

and "n" was not happy-making.

The better bogus line solves the problem for the naive empty loop, and solves the crash for this bug. However, debugging the program for this bug is still not good -- it hangs (in deadloop), unless I set a breakpoint on line 1 (!).

If the debuggers could be convinced to all set a breakpoint in runtime.InfiniteLoop, that would work, also.


Related questions

cmd/link: segmentation fault during mach-o linking
cmd/go: cannot find module providing package error stops `go get` processing hot 3
vendor/ undefined: errors.Frame ... hot 2
cmd/vet: potential false positive in the "suspect or" check hot 2
cmd/go: needs a better error than "missing dot in first path element" when GOROOT is set incorrectly hot 2
x/xerrors: fails to compile on tip hot 1
cmd/go: `go clean <package>` downloads modules hot 1
cmd/cgo error: runtime: unknown pc 0x7fff5c805b86 hot 1
runtime: crash with "invalid pc-encoded table" hot 1
cmd/link: showing many ld warnings of "building for macOS, but linking in object file" hot 1
runtime: go program crach, it seems fall into infinite loop hot 1
cmd/go: major version without preceding tag must be v0, not v1 - breaks build of hot 1
gollvm: Using External Go Packages with gollvm hot 1
runtime: macOS Sierra builders spinning hot 1
cmd/go: Problem using go modules hot 1
Github User Rank List