TUI for inspecting crash reports

[mitchellh]

#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]

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]

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]

#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.

[furtidev]

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.

[marco-zan]

Hi! I would be a first time contributor, and i would like to work on this issue, but i wanted to understand the size size and scope of this.

Starting super small, this could this just work as a "pipe text into less", with a list to choose the one to open. Or we can go full-fledge with a TUI that has the usual list on the left, page on the right with navigation using arrows and hjkl, and maybe with support for search with "/"

Clearly there are pros and cons choosing both of them, the first one is simple but if no more is needed, than it could be a good idea. The second one could be customized further, but i don't know if thats needed and worth it. The two options are there just because I want to understand this better, but please tell me everything you want to come out of this.

Also i cannot make ghostty make a crash report even with the keybinding, so i will need a crash file to do testing, while opening a dedicated issue

[jcollie]

Crash reports have been disabled on Linux as they are pretty useless - they don't include the symbols necessary to make use of the crash reports. So if you're not on macOS this is going to be a very difficult feature to develop. Also, there are quite a few privacy/security concerns about data leaks with crash reports. So I think that the first step should be finishing the crash report decoder (it was never finished) so that crash reports can be inspected (and perhaps redacted). Getting them working on Linux would be a bonus.

[marco-zan]

I started reading through the code to understand it. My question is, are the crash reports on linux currently useless because the decoder is not finished? In that case, I would like to enable them and then work on the decoder. If that's not the case, i would install macos on a VM and look at ghostty from there, and think about linux later

[jcollie]

are the crash reports on linux currently useless because the decoder is not finished

I believe that it is more than just decoding, Linux crash reports are missing usable stack traces. You should be able to enable stack traces on Linux by recompiling with -Dsentry=true.

[marco-zan]

Ok I started working on sentry envelope decoding, I'll open a PR as soon as I have some code ready