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

Open
jdef opened this Issue Mar 22, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@jdef

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

This comment has been minimized.

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 from call stack contains frame that captures func pointer reference to runtime: panic stack trace includes closure from method value Mar 22, 2018

@bcmills

This comment has been minimized.

Member

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

This comment has been minimized.

Member

bcmills commented Mar 22, 2018

See also #16723.
(CC: @aclements)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment