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

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

macos:
$ go version
go version go1.13.6 darwin/amd64

linux:
# 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`)?

go env Output

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="https://goproxy.cn,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"
linux:
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=“https://goproxy.cn,direct”
GOROOT=“/root/.bin/go1.13.6”
GOSUMDB=“sum.golang.org”
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”

What did you do?

I have a go source file:

$
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!")
	}
}

I ran the commands below and got a panic:

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.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 21 (19 by maintainers)

Most upvoted comments

How do you feel about

%  dlv exec ./bogo
Type 'help' for list of commands.
(dlv) b main.main
Breakpoint 1 set at 0x1056fd0 for main.main() ./bogo.go:8
(dlv) c
> main.main() ./bogo.go:8 (hits goroutine(1):1 total:1) (PC: 0x1056fd0)
Warning: debugging optimized function
     3:     func call() {
     4:          println("called!")
     5:     }
     6:     
     7:     func main() {
=>   8:          for { }
     9:     }
(dlv) n
> main.main() <infiniteloop>:1 (PC: 0x1056fd1)
Warning: debugging optimized function
(dlv) n
> main.main() ./bogo.go:8 (hits goroutine(1):2 total:2) (PC: 0x1056fd0)
...

dr2chase on Jan 17, 2020

My first stab at this turned into a mess.

dr2chase on Jan 17, 2020

That bad line number is intentional; it’s to prevent an infinite loop stepping in the debugger. See https://go-review.googlesource.com/c/go/+/168477

Perhaps the debuggers are smarter now. @cherrymui had an idea that we should just write “runtime.InfiniteLoop()” and for any effect-free infinite loops that we detect (like this one), replace the code with a call to that. It will of course deschedule the goroutine, and the name speaks for itself to anyone debugging their code, and we can get rid of these line number shenanigans.

Saves energy, too.

dr2chase on Jan 15, 2020