Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: make panic dumps more readable #11850
When a Go program panics, it dumps information on running goroutines, stack trace, error etc. But it's hard for humans to parse. In a terminal, which is where you're most likely to see panics as you're testing your program, the error message is the first line and you have to scroll to see it.
Python does this really well, as they should, since everything is a runtime "panic". The last line is the error message. Then there's a blank line, and then the stack trace in reverse order, so that the frame that had the error is the next line reading up. 95% of the time those last two lines are all you need to see to understand what's going wrong.
I'd like to see Go lay things out similarly, with the most important information at the bottom, and the least important at the top. It would make debugging Go programs in the terminal a little bit more pleasant. Again that would be the most common case for seeing a panic by far. Production panics are hopefully few and far between.
It looks like at least one popular public tool, panicparse, depends on the current format. Not to mention private tools that may also depend on the current format. Technically, the format doesn't seem to be subject to Go1 compatibility since it would probably fall under "Unspecified behavior" - I don't see any mention of panic dump format in the spec. However, since this doesn't seem so critical, we should probably hold off until Go2 so we don't needlessly break existing tools.
(@ianlancetaylor based on my reasoning, do you think this should be tagged with Go2?)
I think we should close this issue.
I don’t think reversing the order of a stack trace is useful for two reasons.
I think you'll see way more stack traces while developing and testing locally than in actual production. Obviously in the first scenario errors are unavoidable and commonplace, in the latter I would hope they're not. Certainly they're more important when they happen in production. But the principle of optimizing for the more common development case would seem to be the best. This is a proposal for a feature to save developers time, and that yields the biggest benefit when multiplied by the largest number of times invoked.
To be clear I don't think we should optimize for the no goroutines case. I don't know how many errors involve multiple goroutines, but I expect it's a large quantity given that's one of the main features of the language. My experience in the industry suggests the same.
Putting important information at the top means it will be above the fold with short terminals or large stack traces, which is also probably most of the time. For example that little tiny integrated terminal at the bottom of vscode that most people use. So I'll boil this down to one question:
Is there any summary information that's usually important in determining what went wrong and where, that we could place at the very bottom of the output (even if it duplicates information) so that panics can be diagnosed in many cases without having to scroll up and pore over the stack traces?
For example, the panic message and the file name and last line in user code code (that is not inside the stdlib or the vendor directory) from the goroutine that had the panic. The rest of the output can stay unchanged, my proposal would only add one lor two lines of additional, duplicated information. Short, succinct, and almost universally what you need to see to take action in diagnosing the problem. Just having that next step in front of you is great for ADD types like me that see a big giant blob of stack traces and get distracted trying to figure out what the next step is.