Pretty Rust backtraces in raw terminal mode | Hacker News Reader

Pretty Rust backtraces in raw terminal mode

werat.dev

66 pointswerat15 comments

I’m glad the author finally figured out that the abstraction he was using was the wrong one and just ended up using a C-like API - calling some global procedures that mutate the (external) global state.

Raw terminal mode is used for TUI programs, so the article is about setting a panic hook to get everything working in that case.

I’m not a rust expert, but perhaps this usecase is particularly hard because you’re holding it wrong? It seems to me that the strength of rust is in preventing panics as much as possible by moving the error checking to the compiler; so sure, fixing the terminal is an interesting challenge, but probably not going to make development any easier.

You can easily make lots of fragile Rust code by poor error handling that cause shitty panics like "Some(2) != None" and suppressing backtraces for even more obscurity. Good backtraces need to be human- and machine-readable. Ideally, you'd throw (pun intended) panic objects (not backtraces) as structured data in individual files. Anyone who gets into reinventing flat log rotation management at scale is holding it wrong.

I think the key there is "as much as possible". It's really hard to guarantee that panics won't happen.

I like Rust, but the panic mechanism is a bit of a weak point in the language. It's not like I have a better solution -- you really do need a way to handle exceptional cases that shouldn't ever happen but aren't statically checkable. But it's unfortunate that it interacts with so many other parts of the language, rather than being orthogonal. Every single API needs to answer "but how does this interact with panics". Rust is a very good language because panics are one of just a couple of things that work this way.

Unsafe code needs to be paranoid about panics, because that’s equivalent of exception safety in C++.

However, other safe Rust code doesn’t need to care that much, because it will either unwind and run destructors, or abort the program. Both are well defined and safe.

Rust uses panics to signal programmer bugs, not normal error handling, so there isn’t much to do about them in the code, because actual “handling” of panics is fixing the bug.

Sort of. There are a bunch of places in the safe API where you have to care. Off the top of my head:

- Lock poisoning and dealing with locks failing to open because they’re poisoned after some other thread panics.

- The whole scoped thread thing.

- Panics across async calls have a bunch of unintuitive (but reasonable once you think through the constraints!) behaviors.

It all comes down to the same thing: a function call could return or it could panic. Even when writing safe code, you have to know what you’re doing to do in case of panic. Usually that’s just passing the panic upward*, but not always, and those behaviors aren’t well-captured in the type system. Because of that, writing truly panic-free Rust is hard to impossible.

I don’t have a better answer than the panicking system. But you do have to care even in safe code, and it is a design weakness.

* I know about panic handlers and abort-on-panic. It doesn’t change the overall point.

I'd say having panics is one of the strengths of Rust; panics cause controlled teardown of the program (typically) instead of nasal demons

Does anyone know of a good solution to pretty print or make more sense of stacktraces in async code?

It's an area of active development! I'm hopeful the situation will improve significantly this year.

For tracing suspended Futures, I've worked on a few approaches:

1. If you don't mind annotating your async functions, you can use the async-backtrace crate, which provides pretty-printing out-of-the-box: https://crates.io/crates/async-backtrace

2. If you are already using the `tracing` ecosystem, you can use the tracing-causality crate (it doesn't yet include pretty-printing, but it's not too hard to add that on): https://crates.io/crates/tracing-causality

3. If you are only supporting Linux (and maybe MacOS) and you aren't stripping away debuginfo from your binaries, you can build atop the deflect crate (https://jack.wrenn.fyi/blog/deflect/). If your `Future` purely consists of `async` blocks, Tyler Mandry's reflection based approach works well: https://github.com/tmandry/rust-dbg-ext/tree/async-backtrace...

For analyzing stack traces of active futures, I'm not aware of any good ways to reliably filter out irrelevant frames (e.g., frames from the runtime).

Thanks! Nice to see that people are experimenting with improving async.

Hmm just adding some ASCII art doesn't really make it pretty. Colorizing the output and making it easier to analyze as well as read, would.

The article wasn't about adding ASCII art, only about allowing the default panic handler to print the output correctly when the application uses raw mode in the terminal. It is a good introduction to what registering a panic handler looks like, no more than that. If you want colored backtraces, you can look at https://crates.io/crates/color-backtrace, https://crates.io/crates/better-panic or https://crates.io/crates/color-eyre, which leverage the same machinery shown in the article.

In this article, I interpret "pretty" to mean "readable". There is a sample of the alternative in the post. Raw mode requires an explicit carriage return to accompany each line feed if you want the CR behavior, so if the default panic handler prints its normal string, each line is horizontally indented to the end of the previous line.

There is no ASCII art.

Ok then I misunderstood, I was going by the ASCII art in the picture.

I don't know much about Rust so I didn't really get the whole story.

Reply on news.ycombinator.com