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: wrong line number for inlined defer function #21877

Closed
johnSchnake opened this issue Sep 14, 2017 · 4 comments
Closed

cmd/compile: wrong line number for inlined defer function #21877

johnSchnake opened this issue Sep 14, 2017 · 4 comments
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@johnSchnake
Copy link

Please answer these questions before submitting your issue. Thanks!

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

go version go1.8.3 darwin/amd64

Does this issue reproduce with the latest release?

Not sure; reproduces on the playground.

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

Playground & locally:

GOARCH="amd64"
GOOS="darwin"

What did you do?

Tried to get the line number on which a defer function call was made; unable to do so and instead get the line number for the end of the function (})

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

Note: if you write the defer as:

defer func(){
    debug.PrintStack()
}

You get what you'd expect since the unnamed function func1 is now considered to be at the end of of the function while the PrintStack() itself is not deferred.

What did you expect to see?

Stack trace similar to the one below but with the line number for main.test() to be 12 (the line the defer function was defined) instead of line 13 (where the function ends).

Seems to relate to #5856 where the fact that there are two lines of relevance for defers: where they are defined and where they are executed and there is a conundrum about how to either provide both or which to provide.

Not sure if this had been solved since then.

What did you see instead?

goroutine 1 [running]:
runtime/debug.Stack(0x0, 0x60c6, 0x10444240, 0x104000e0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0xc0
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x20
main.test()
	/tmp/sandbox495784442/main.go:13 +0x7b
main.main()
	/tmp/sandbox495784442/main.go:8 +0x20
@ianlancetaylor ianlancetaylor changed the title Unable to get line number from inlined defer function cmd/compile: wrong line number for inlined defer function Sep 14, 2017
@ianlancetaylor ianlancetaylor added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Sep 14, 2017
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Sep 14, 2017
@rajathagasthya
Copy link
Contributor

Is this suitable for new contributors to fix? I'd like to help if it is (or even if it isn't, with some hand holding).

@ianlancetaylor
Copy link
Contributor

@mdempsky See question above from @rajathagasthya , thanks.

@mdempsky
Copy link
Member

This appears to be working as intended to me. In call stacks, we make deferred functions appear to be called wherever they're dynamically invoked from. In the case of a non-panicking return, this is wherever the return statement is; or in this particular case, at the implicit return statement at the }.

@johnSchnake
Copy link
Author

@mdempsky I agree, but if you want to programmatically inspect the function call by looking at the line number, is there any way that is possible?

In theory if you detect the line given is the end of the function (}) then you could scan through the function to find a defer, but if you had multiple defer functions then there seems to be 0 way in which to differentiate them at runtime. Am I mistaken in that belief?

@golang golang locked and limited conversation to collaborators Sep 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants