Description
What version of Go are you using (go version
)?
1.16.3
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env ubuntu@jordan-test-0001:~$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/ubuntu/.cache/go-build" GOENV="/home/ubuntu/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/ubuntu/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/ubuntu/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.16.3" 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-build1750380533=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I attempted to use viewcore
on a core dump from CockroachDB. I ran the CockroachDB binary, killed it with SIGSEGV
, and collected the resultant dump. Then, I ran viewcore
with the overview
argument.
./go/bin/viewcore /mnt/data1/cores/core.cockroach.13188.jordan-test-0001.1620268383 --exe ./cockroach overview
What did you expect to see?
Viewcore output, which could hopefully help me track down some issues with memory usage. 😄
What did you see instead?
A panic:
ubuntu@jordan-test-0001:~$ ./go/bin/viewcore /mnt/data1/cores/core.cockroach.13188.jordan-test-0001.1620268383 --exe ./cockroach overview
panic: bad int32 type uint32
goroutine 1 [running]:
golang.org/x/debug/internal/gocore.region.Int32(0xc0004fa000, 0x777bdec, 0xc000182550, 0x86201a)
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/internal/gocore/region.go:82 +0xc6
golang.org/x/debug/internal/gocore.(*module).readFunc(0xc00f4cee70, 0xc0004fa000, 0x777bdd8, 0xc000aa86e0, 0xc0004fa000, 0x80ee0e8, 0xc000183d60, 0xc000182280)
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/internal/gocore/module.go:62 +0x22e
golang.org/x/debug/internal/gocore.(*Process).readModule(0xc0004fa000, 0xc0004fa000, 0x80ee080, 0xc000a58a50, 0x80ee080)
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/internal/gocore/module.go:45 +0x4cc
golang.org/x/debug/internal/gocore.(*Process).readModules(0xc0004fa000)
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/internal/gocore/module.go:26 +0x1a7
golang.org/x/debug/internal/gocore.Core(0xc000162000, 0x41, 0x0, 0x0)
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/internal/gocore/process.go:156 +0x2c8
main.readCore(0x78f037, 0xc00015c700, 0xc00011fd80, 0xc00011fda8)
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/cmd/viewcore/main.go:266 +0xdb
main.runOverview(0xb05b80, 0xc000034260, 0x0, 0x2)
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/cmd/viewcore/main.go:378 +0x34
github.com/spf13/cobra.(*Command).execute(0xb05b80, 0xc000034200, 0x2, 0x2, 0xb05b80, 0xc000034200)
/home/ubuntu/go/pkg/mod/github.com/spf13/[email protected]/command.go:766 +0x2c2
github.com/spf13/cobra.(*Command).ExecuteC(0xb05200, 0x0, 0xac76e0, 0xc00007a058)
/home/ubuntu/go/pkg/mod/github.com/spf13/[email protected]/command.go:852 +0x2fe
github.com/spf13/cobra.(*Command).Execute(...)
/home/ubuntu/go/pkg/mod/github.com/spf13/[email protected]/command.go:800
main.main()
/home/ubuntu/go/pkg/mod/golang.org/x/[email protected]/cmd/viewcore/main.go:244 +0x125
Here is a link to the core dump (334 MB): https://drive.google.com/file/d/1KlwSvP-5xxghBRHprxsmtFFQtsK9zAmg/view?usp=sharing
Here is a link to the binary used (178 MB): https://drive.google.com/file/d/147h4wTi7WloFWPjIXm4kZoIGPNvu6QNz/view?usp=sharing
I know this is a bit of a heavy repro, but I'm not quite sure how else to track down the issue. Any ideas would be appreciated for how to produce a smaller case for you to look at.
@randall77, would you have an idea about this issue? I saw #38638, but this appears to be a different issue.
Thank you!