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: Make panic dumps more readable #11850

Open
eloff opened this Issue Jul 24, 2015 · 3 comments

Comments

Projects
None yet
4 participants
@eloff

eloff commented Jul 24, 2015

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.

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jul 24, 2015

@ianlancetaylor ianlancetaylor changed the title from Make panic dumps more readable to runtime: Make panic dumps more readable Jul 24, 2015

@meirf

This comment has been minimized.

Member

meirf commented Jul 5, 2018

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?)

@davecheney

This comment has been minimized.

Contributor

davecheney commented Jul 5, 2018

I think we should close this issue.

I don’t think reversing the order of a stack trace is useful for two reasons.

  1. The most useful place for a stack trace is in reporting a bug in production. In which case, the current behaviour, the faulting goroutine at the top of the stack trace and the faulting line directly following the panic message is optimal.
  2. Reversing be order of a goroutines stack trace is optimising for the simple case — no cocurrency. Reversing the ordered of printing stack frames would mean the faulting goroutine is (probably) the first one printed but the faulting line is in the middle of the stack trace.
@eloff

This comment has been minimized.

eloff commented Jul 5, 2018

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.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment