Skip to content

/go

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: Caller returns wrong file and line if called in a deferred function during panic #26320

Open
ainar-g opened this Issue Jul 10, 2018 · 4 comments

Comments

Assignees
No one assigned
Labels
NeedsInvestigation
Projects
None yet
Milestone
  Go1.13
6 participants
@ainar-g @odeke-em @randall77 @gopherbot @ianlancetaylor @andybons
@ainar-g
Copy link
Contributor

ainar-g commented Jul 10, 2018

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

Does this issue reproduce with the latest release?

Tested on b001ffb.

What did you do?

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

What did you expect to see?

    return: main.go:13
     panic: main.go:18

What did you see instead?

    return: main.go:13
     panic: asm_amd64p32.s:459

This bug was found in the discussion of #26275.

@ainar-g ainar-g referenced this issue Jul 10, 2018

Open

runtime: document the behaviour of Caller and Callers when used in deferred functions #26275

@ianlancetaylor ianlancetaylor added the NeedsInvestigation label Jul 10, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 10, 2018

@odeke-em

This comment has been minimized.

Sign in to view
Copy link
Member

odeke-em commented Nov 9, 2018

Kindly paging @aclements @davidlazar
@randall77

This comment has been minimized.

Sign in to view
Copy link
Contributor

randall77 commented Dec 28, 2018

Would:

     return: main.go:13
     panic: panic.go:522

Make any more sense? That's the implementation of panic in the runtime.
The parent of that frame would be main.go:18.
@ainar-g

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

ainar-g commented Dec 28, 2018

@randall77 That looks better in that there is no mention of the assembly files, but it is still not the correct behaviour the way I see it. I think there shouldn't be any difference between the printLine calls in f1 and f2.
@gopherbot

This comment has been minimized.

Sign in to view
Copy link

gopherbot commented Dec 28, 2018

Change https://golang.org/cl/152537 mentions this issue: cmd/compile,runtime: redo mid-stack inlining tracebacks

gopherbot pushed a commit that referenced this issue Dec 28, 2018

@randall77
cmd/compile,runtime: redo mid-stack inlining tracebacks 
Work involved in getting a stack trace is divided between
runtime.Callers and runtime.CallersFrames.

Before this CL, runtime.Callers returns a pc per runtime frame.
runtime.CallersFrames is responsible for expanding a runtime frame
into potentially multiple user frames.

After this CL, runtime.Callers returns a pc per user frame.
runtime.CallersFrames just maps those to user frame info.

Entries in the result of runtime.Callers are now pcs
of the calls (or of the inline marks), not of the instruction
just after the call.

Fixes #29007
Fixes #28640
Update #26320

Change-Id: I1c9567596ff73dc73271311005097a9188c3406f
Reviewed-on: https://go-review.googlesource.com/c/152537
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
69c2c56

@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.