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

runtime: panic stack trace includes closure from method value #24488

Closed
jdef opened this issue Mar 22, 2018 · 4 comments
Closed

runtime: panic stack trace includes closure from method value #24488

jdef opened this issue Mar 22, 2018 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@jdef
Copy link

jdef commented Mar 22, 2018

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

go version go1.10 linux/amd64

Does this issue reproduce with the latest release?

yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/vagrant/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/vagrant/workspace-dss"
GORACE=""
GOROOT="/usr/local/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go-1.10/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-build161669454=/tmp/go-build -gno-record-gcc-switches"

What did you do?

It's may also be reproduced by examining the call stack of a panic. For example:
https://play.golang.org/p/579SSX2Vx5t

What did you expect to see?

hi
panic: stack trace

goroutine 1 [running]:
main.Func.Bar(0x11d5a8, 0x1738e0)
	/tmp/sandbox941741331/main.go:19 +0x60
main.Func.Foo(0x1040c128, 0x0)
	/tmp/sandbox941741331/main.go:11 +0x40
main.main()
	/tmp/sandbox941741331/main.go:25 +0x80

What did you see instead?

hi
panic: stack trace

goroutine 1 [running]:
main.Func.Bar(0x11d5a8, 0x1738e0)
	/tmp/sandbox941741331/main.go:19 +0x60
main.(Func).Bar-fm()
	/tmp/sandbox941741331/main.go:24 +0x40
main.Func.Foo(0x1040c128, 0x0)
	/tmp/sandbox941741331/main.go:11 +0x40
main.main()
	/tmp/sandbox941741331/main.go:25 +0x80

This is a problem for code that expects to reliably count frames on the stack based on the function calls actually made (e.g. logging modules that want to track file/line of the caller). When artificial frames are injected into the call stack (due to passing around a function reference and later invoking it) this becomes confusing and hard to deal with when attempting to determine the file/line of the caller. It also seems semantically incorrect: the assignment of func Bar to a variable IS NOT a call to the function, so it should not be in the caller stack.

@jdef
Copy link
Author

jdef commented Mar 22, 2018

To be clear, this was first observed when troubleshooting a failing unit test on a project that was attempting to use runtime.Caller. The reproduction use case using panic seemed more concise, so that's what I linked to. If needed I can provide a reproduction using runtime.Caller instead.

@bcmills bcmills changed the title call stack contains frame that captures func pointer reference runtime: panic stack trace includes closure from method value Mar 22, 2018
@bcmills
Copy link
Contributor

bcmills commented Mar 22, 2018

Per https://golang.org/ref/spec#Method_values:

These two invocations are equivalent:

t.Mv(7)
f := t.Mv; f(7)

That does seem to imply that the method value should not be treated as a separate function call.

@bcmills bcmills added this to the Go1.11 milestone Mar 22, 2018
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 22, 2018
@bcmills
Copy link
Contributor

bcmills commented Mar 22, 2018

See also #16723.
(CC: @aclements)

@gopherbot
Copy link

Change https://golang.org/cl/153477 mentions this issue: runtime: proper panic tracebacks with mid-stack inlining

@golang golang locked and limited conversation to collaborators Jan 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants