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

Jump to bottom

x/debug/cmd/viewcore: panic on missing pctab entry #27323

Closed
rhysh opened this issue Aug 28, 2018 · 4 comments
Closed

x/debug/cmd/viewcore: panic on missing pctab entry #27323

rhysh opened this issue Aug 28, 2018 · 4 comments
Labels
FrozenDueToAge
Milestone
Unreleased

Comments

@rhysh
Copy link
Contributor

rhysh commented Aug 28, 2018

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

$ go1.10 version
go version go1.10.4 darwin/amd64
$ (cd $(go list -f '{{.Dir}}' golang.org/x/debug/cmd/viewcore) && git rev-parse HEAD)
1ff449a1b670fb60da59e170803373318549b845

Does this issue reproduce with the latest release?

This is the latest revision of golang.org/x/debug/cmd/viewcore, golang/debug@1ff449a. It fails with go1.10.4 and also with go1.11.

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

As in #27322, I'm using a darwin/amd64 machine to load a linux/amd64 core dump. The core dump is the same as in that report. I'm not able to share the core dump or the executable; they're for a closed-source program. The program that crashed was built with go1.10.3 (with minor patches).

$ go1.10 env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rhys/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/rhys/go"
GORACE=""
GOROOT="/Users/rhys/go/version/go1.10"
GOTMPDIR=""
GOTOOLDIR="/Users/rhys/go/version/go1.10/pkg/tool/darwin_amd64"
GCCGO="gccgo"
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/49/zmds5zsn75z1283vtzxyfr5hj7yjq4/T/go-build447726636=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I ran viewcore with a core file. I specified an executable, although it's at a different path on my darwin/amd64 laptop than it was on the linux/amd64 server that dumped core.

What did you expect to see?

I hoped to see a view of the core file if I'd provided appropriate arguments. Otherwise, I expected an error message explaining how the arguments I provided were inappropriate.

I've provided the same core file and executable to Delve, which has been able to show me goroutines and stack traces as I'd expect.

What did you see instead?

$ viewcore /path/to/core-file --exe /path/to/downloaded-executable
panic: can't find pctab entry

goroutine 1 [running]:
golang.org/x/debug/internal/gocore.(*pcTab).find(0xc4229d8e98, 0x1f, 0xc4229d8e60)
	/Users/rhys/go/src/golang.org/x/debug/internal/gocore/module.go:177 +0x78
golang.org/x/debug/internal/gocore.(*Process).readFrame(0xc4208d8000, 0xc420533d68, 0xa32d3f, 0xc4223b1a90)
	/Users/rhys/go/src/golang.org/x/debug/internal/gocore/process.go:562 +0x95
golang.org/x/debug/internal/gocore.(*Process).readG(0xc4208d8000, 0xc4208d8000, 0xc420000a80, 0xc42048e500, 0xc420000a80)
	/Users/rhys/go/src/golang.org/x/debug/internal/gocore/process.go:519 +0x57f
golang.org/x/debug/internal/gocore.(*Process).readGs(0xc4208d8000)
	/Users/rhys/go/src/golang.org/x/debug/internal/gocore/process.go:466 +0x130
golang.org/x/debug/internal/gocore.Core(0xc42015c000, 0x70, 0x0, 0x0)
	/Users/rhys/go/src/golang.org/x/debug/internal/gocore/process.go:157 +0x2fd
main.readCore(0x4, 0x4, 0x4, 0x3)
	/Users/rhys/go/src/golang.org/x/debug/cmd/viewcore/main.go:260 +0xd1
main.runRoot(0x169dde0, 0xc420136440, 0x0, 0x2)
	/Users/rhys/go/src/golang.org/x/debug/cmd/viewcore/main.go:279 +0x47
golang.org/x/debug/cmd/viewcore/vendor/github.com/spf13/cobra.(*Command).execute(0x169dde0, 0xc4200ac0e0, 0x2, 0x2, 0x169dde0, 0xc4200ac0e0)
	/Users/rhys/go/src/golang.org/x/debug/cmd/viewcore/vendor/github.com/spf13/cobra/command.go:766 +0x2c1
golang.org/x/debug/cmd/viewcore/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x169dde0, 0xc4200aa4e0, 0x169e040, 0x169e2a0)
	/Users/rhys/go/src/golang.org/x/debug/cmd/viewcore/vendor/github.com/spf13/cobra/command.go:852 +0x30a
golang.org/x/debug/cmd/viewcore/vendor/github.com/spf13/cobra.(*Command).Execute(0x169dde0, 0x1447cf3, 0x1)
	/Users/rhys/go/src/golang.org/x/debug/cmd/viewcore/vendor/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
	/Users/rhys/go/src/golang.org/x/debug/cmd/viewcore/main.go:238 +0xbf

CC @heschik
@gopherbot gopherbot added this to the Unreleased milestone Aug 28, 2018
@heschi
Copy link
Contributor

heschi commented Aug 29, 2018

This was during an investigation of (a variant of?) #24925. So the problem should be basically the same: it's gone off the rails trying to backtrace the nanotime call. We still shouldn't crash.

@hyangah

@gopherbot
Copy link

Change https://golang.org/cl/132055 mentions this issue: internal/gocore: don't panic if backtrace fails

@heschi
Copy link
Contributor

heschi commented Aug 29, 2018 •
edited

@rhysh, if you still have the core can you try that change? I don't have a test case handy.

@rhysh
Copy link
Contributor Author

rhysh commented Aug 29, 2018

CL 132055 PS 1 does the trick, thanks. Here's the (new) warning it prints when loading the core:

warning: giving up on backtrace: cannot read frame size at pc=0xa32d3f: can't find pctab entry for offset 0x4

@golang golang locked and limited conversation to collaborators Aug 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
3 participants
@rhysh @gopherbot @heschi