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

cmd/compile: spurious stack frame for inlined method of returned value #21879

Closed
ChrisHines opened this issue Sep 14, 2017 · 3 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@ChrisHines
Copy link
Contributor

What did you do?

https://play.golang.org/p/ZJ4aswqjbQ

package main

import "runtime/debug"

func main() {
	// correct
	println(trace().stack)

	// also correct
	t := trace()
	println(t.getStack())

	// inlined getStack method appears in stack trace
	// as the caller of func trace()
	println(trace().getStack())
}

func trace() callStack {
	return callStack{
		stack: string(debug.Stack()),
	}
}

type callStack struct {
	stack string
}

func (c callStack) getStack() string {
	return c.stack
}

https://play.golang.org/p/wVO2lrLiAk

package main

import (
	"runtime"
)

func main() {
	// prints "main.main" as expected
	println(caller().frame.Function)

	// prints main.call.name with default compile, but prints "main.main" if
	// compiled with -gcflags="-l"
	println(caller().name())
}

func caller() call {
	var pcs [3]uintptr
	n := runtime.Callers(1, pcs[:])
	frames := runtime.CallersFrames(pcs[:n])
	frame, _ := frames.Next()
	frame, _ = frames.Next()

	return call{frame: frame}
}

type call struct {
	frame runtime.Frame
}

func (c call) name() string {
	return c.frame.Function
}

What did you expect to see?

  • Methods called after a stack trace has been captured should not appear in the stack trace.

What did you see instead?

  • The getStack and name methods logically called after a stack trace had been captured appear in the stack trace as the caller of a function they don't call.
@ChrisHines
Copy link
Contributor Author

This appears to be new with Go 1.9. I can reproduce it on the playground (links above) and on go version go1.9 windows/amd64, but not on go version go1.8.3 darwin/amd64.

@ianlancetaylor ianlancetaylor added this to the Go1.10 milestone Sep 15, 2017
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 15, 2017
@ianlancetaylor
Copy link
Contributor

CC @mdempsky

@mdempsky mdempsky self-assigned this Sep 18, 2017
@gopherbot
Copy link

Change https://golang.org/cl/64470 mentions this issue: cmd/compile: fix stack frame info for calls in receiver slot

@golang golang locked and limited conversation to collaborators Sep 19, 2018
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