runtime: stacktrace for deferred code which panics is too subtle for me #45794
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
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:
A lot of what you ask for is there, albeit somewhat hidden.
Halfway down your stack trace, there is a panic. That's the nil map panic. The subsequent entries are the stack from there until the double-unlock throw.
I'm surprised there's nothing at line 16. I thought we made defers look like they were called at the closing bracket of the function that deferred them. Maybe that's only defers called from the non-panic path, though.
I feel like there might be something to fix here, but I'm not sure what concrete steps that would involve.
Yes. For panicking case the return statement (or the implicit return at the end of the function) is not executed, and the deferred the function is not triggered from there.
This example is also interesting in that it is a runtime fatal error, instead of an ordinary user panic. For an ordinary panic, many intermediate runtime frames are not shown: https://play.golang.org/p/nlGlx9cSQ5y