Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pretty Rust backtraces in raw terminal mode

werat.dev

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Pretty Rust backtraces in raw terminal mode

#11

Post by jswrenn »

zaynetro wrote: post #7

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

Re: Pretty Rust backtraces in raw terminal mode

#12

Post by zokier »

vermilingua wrote: post #4

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.

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

Re: Pretty Rust backtraces in raw terminal mode

#13

Post by pornel »

ddulaney wrote: post #6
vermilingua wrote: post #4

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.

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, r…

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.

Re: Pretty Rust backtraces in raw terminal mode

#14

Post by ddulaney »

pornel wrote: post #13
ddulaney wrote: post #6

Earlier quoted context omitted.

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, r…

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 pa…

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.

Re: Pretty Rust backtraces in raw terminal mode

#15

Post by wkat4242 »

kaelinl wrote: post #10
wkat4242 wrote: post #3

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.

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.

Re: Pretty Rust backtraces in raw terminal mode

#16

Post by zaynetro »

jswrenn wrote: post #11
zaynetro wrote: post #7

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 tracin…

Thanks! Nice to see that people are experimenting with improving async.
Post reply on HN