Tracking Issue for `backtrace_frames`

[seanchen1991]

This is a tracking issue for one of the features mentioned in #81022, the ability to create an iterator over backtrace frames.
The feature gate for the issue is #![feature(backtrace_frames)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the capability to return an iterator over the Backtrace type
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• We're opting to not derive Clone on the Backtrace type so as not to expose a public Backtrace::clone method. Private clone methods are implemented instead. Is this the long-term API we'll want to stick with?
• We'll want to think about the FromIterator implementation a bit more, because we can't mark trait implementations as unstable so if we added one to Backtrace we'd be committing to it right away.

Implementation history

• Add Frames Iterator for Backtrace #81022 adds a frames method on the Backtrace type that returns a Vec<BacktraceFrame> that can be iterated over.

[seanchen1991]

@rustbot modify labels +T-libs

[rustbot]

Error: Label B-unstable can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

[petrochenkov]

Apologies if I'm late to the party, or if all of this was discussed before, but I'd suggest studying the C++ stacktrace proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0881r7.html) before stabilizing things like this.

The interface is based on Boost.Stacktrace and was heavily scrutinized and changed in non-obvious ways to accommodate for some backtrace operations being expensive or platform-dependent.

[seanchen1991]

@petrochenkov Looking through the linked document, I don't really see anything that is within scope of this PR. Please let me know if there's any specific points in the doc that should be brought up though; I certainly might have missed something.

[KodrAus]

The Backtrace::frames method currently returns a &'a [BacktraceFrame], which gives us slicing, indexing, and iteration for free. We might want to consider a BacktraceFrames<'a> wrapper though that gives us more wiggle room for lazy resolution. It'll just mean adding more types and boilerplate since we'll need to implement traits for all the iteration and slicing ourselves.

[iddm]

I have just looked at the Backtrace stabilisation announcement in 1.65. However, I wonder, what's the use of it if we can't traverse the frames? I believe the primary use of a stack trace like that would be the possibility to walk over the frames and be able to analyse them in any manner rather than just printing. For example, I'd think of having something like this: https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html
How come the "Backtrace" is said to be stabilised while the most crucial and juicy part of it isn't?

[John-Nagle]

I see this issue has been in progress for over two years now.

Here's a use case. I have a GUI program, a metaverse client. One of those things for end users who are not programmers. There's no text console. There are multiple threads. If a thread panics, I need to capture a backtrace, log it, tell the user something via a GUI dialog, and shut down the program.

The only thing you can do with a Backtrace right now is format it. You can't iterate over it in production code. Can't even clone it. If you format it, 80% of the output is the panic and backtrace system doing its thing..

I'd like to have both the ability to iterate over a backtrace, and something that extracts only the frames relevant to the cause of the panic. In the playground linked here, the only two relevant lines, out of 30, are:

7: playground::called_by_worker
             at ./[src/main.rs:5](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=694b6273d3b16c092591de206eefaa17#):5
8: playground::worker
             at ./[src/main.rs:9](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=694b6273d3b16c092591de206eefaa17#):5

Everything else is the panic and backtrace system's own machinery. And the included URLs are useless unless you're in a development environment. None of this stuff is oriented towards reporting problems detected in the field.

Could be worse. What you get from catch_unwind is an Any that can't even be formatted.

[Thomasdezeeuw]

The only thing you can do with a Backtrace right now is format it. You can't iterate over it in production code. Can't even clone it. If you format it, 80% of the output is the panic and backtrace system doing its thing..

I've been thinking about reducing the backtrace length as well. It would be great if we could use something like std::panic::Location to trim backtraces to the starting point we're interested in, skipping over the frames for the function(s) to handle and capture the backtrace.

Could be worse. What you get from catch_unwind is an Any that can't even be formatted.

You can actually convert the value into a String or &str, see https://github.com/Thomasdezeeuw/heph/blob/8725fe9ed871f135b7ab87b5969eb1213121a242/src/actor/future.rs#L196-L204. Although it's not guaranteed to catch everything I think it handles most of it (at least all panics I've seen in years of Rust programming)