Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: Caller returns wrong file and line if called in a deferred function during panic #26320
What version of Go are you using (
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 <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: David Chase <email@example.com>
The assembly function is now no longer reported. We now report the
This currently prints:
I think the crux if the issue is that when doing the
But maybe for
I'm not sure exactly what the mechanism for that would be - we'd need to skip frames between the gopanic and the frame of the current defer (which might recover, so still might be live). And I can't wrap my head around what we'd want for recursive panics (panics in defers that were being run due to a panic).
FYI, if I comment out the panic line, we get the following output:
which does argue for hiding the intervening functions in the traceback.
In any case, punting to 1.14.