Skip to content
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

TUI for inspecting crash reports #2182

Open
3 tasks
mitchellh opened this issue Sep 2, 2024 · 4 comments
Open
3 tasks

TUI for inspecting crash reports #2182

mitchellh opened this issue Sep 2, 2024 · 4 comments
Labels
contributor friendly A well-scoped, approachable issue for someone looking to contributor. gui GUI or app issue regardless of platform (i.e. Swift, GTK)

Comments

@mitchellh
Copy link
Contributor

mitchellh commented Sep 2, 2024

#2173 was merged, which now generates crash reports.

It'd be nice if there was a Ghostty CLI that showed a TUI for inspecting the crash reports. This way users can be confident in what they contain before sending them to the project with a bug report. The crash reports are based on a publicly documented format and I already started a decoder so it shouldn't be too hard to bring this in.

I should note that our crash reports also likely contain a minidump (binary) formatted crash dump from Breakpad. Decoding this format would be nice one day but is a much larger task and out of scope for what I was imagining to close this issue.

My current thinking is that we'd expose this via ghostty +crash-report. I like smaller PRs so I recommend breaking this down into various stages (not in any specific order)

  • List available crash reports (ghostty +crash-report with no args)
  • Inspect a single crash report (ghostty +crash-report <path> or selecting one from the list)
  • Deleting crash reports

There is more we can do but this would be nice to work on.

@mitchellh mitchellh added enhancement contributor friendly A well-scoped, approachable issue for someone looking to contributor. labels Sep 2, 2024
@mitchellh
Copy link
Contributor Author

I will add: if you want to test crash reporting, #2173 introduced a keybinding you can use to generate a crash in a specific thread, the crash binding. Example:

keybind=x=crash:main
keybind=x=crash:render
keybind=x=crash:io

And remember, crash reports are generated on the next start of Ghostty. During an active crash, the crash capture just dumps the information it needs to generate the crash report the next time it runs.

@jcollie
Copy link
Collaborator

jcollie commented Sep 2, 2024

I've got a super basic start on the +crash-report action in #2184. All it does for now is just list available crash reports.

@mitchellh
Copy link
Contributor Author

#2203 lays a lot of groundwork to make this easier, adds decoding structured types from an envelope and also reserialization if we ever implement modification.

@mitchellh mitchellh added gui GUI or app issue regardless of platform (i.e. Swift, GTK) and removed enhancement labels Oct 2, 2024
@furtidev
Copy link
Contributor

furtidev commented Nov 11, 2024

I was taking a look at #2184 and I think a TUI will work well for tty output too. I'm imagining simple navigation, choosing a report opens it up in the inspector. So, I guess the crash report inspector should be implemented first. I might take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributor friendly A well-scoped, approachable issue for someone looking to contributor. gui GUI or app issue regardless of platform (i.e. Swift, GTK)
Projects
None yet
Development

No branches or pull requests

3 participants