runtime: stacktrace for deferred code which panics is too subtle for me #45794
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
https://play.golang.org/p/dS4pD8LBsfH
Reproduced with 1.16.3.
What did you expect to see?
Any way to guess what was deferred, or ideally, where it was deferred.
If you substitute a function literal, like
defer func() { foo.mu.Unlock() }()
, you get to see the name as [function].func1, which helps a lot, but if you just have a direct call to something in runtime, it's pretty hard to read.But also, I'd like to see the original "write to nil map" panic and not have it get swallowed by the second panic from the deferred code.
What did you see instead?
A stack trace which looks like something in runtime double-unlocked, even though actually it's my code that has the bug, and no reference to the line of code where the defer was.
It's conceivable that a clearer unwinding of this could show some of that information, although it's a bit tricky to express clearly. This might actually be two distinct requests for changes to the stack trace, one for "the defer should be annotated with its source line", and one for "it'd be nice not to lose the original panic". I'm not sure.
The text was updated successfully, but these errors were encountered: