Repository navigation
Support hiding specific stackframes from backtrace by marking on the original functions. #68336
Description
Recently #[track_caller] usages has landed on nightly channel, which is really great! However i want to request a little more here. Currently
fn main() {
panic!("foo");
}output is:
thread 'main' panicked at 'foo', src/main.rs:2:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:77
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1057
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1426
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:204
9: std::panicking::default_hook
at src/libstd/panicking.rs:224
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:472
11: std::panicking::begin_panic
at /rustc/689fca01c5a1eac2d240bf08aa728171a28f2285/src/libstd/panicking.rs:399
12: playground::main
at src/main.rs:2
13: std::rt::lang_start::{{closure}}
at /rustc/689fca01c5a1eac2d240bf08aa728171a28f2285/src/libstd/rt.rs:67
14: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:52
15: std::panicking::try::do_call
at src/libstd/panicking.rs:305
16: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:86
17: std::panicking::try
at src/libstd/panicking.rs:281
18: std::panic::catch_unwind
at src/libstd/panic.rs:394
19: std::rt::lang_start_internal
at src/libstd/rt.rs:51
20: std::rt::lang_start
at /rustc/689fca01c5a1eac2d240bf08aa728171a28f2285/src/libstd/rt.rs:67
21: main
22: __libc_start_main
However, of the 22 stack frames, only 3 or 4 is meaningful to user. It would be great if rest of the functions can be marked with a special attribute, and maybe marked somehow in the mangled symbol, then be excluded from the default display of backtrace.
Reacted by csmoe, Diana, Corey Farwell, Daniel García, Ames, Kevin Barabash, Mads Marquart, Taewoo An, Austin Tasato, Ragnar Groot Koerkamp and 3 more
Activity
crlf0710 commentedon Jan 18, 2020
@rustbot modify labels to +A-runtime +C-feature-request +T-lang
ehuss commentedon Jan 18, 2020
I would say this is a duplicate of #58554. There is a long history of filtering irrelevant frames, see #38165 (implemented filtering), #25621, #60852 removed the (broken) filtering when switching to the backtrace crate.
crlf0710 commentedon Jan 18, 2020
@ehuss #58554 talks about removing some frames at the start and end of the backtrace. That's quite limited and error-prone to me. In the above example, i think it will be great if we filter out 0-3, 6, 8-10, 13-17, 19, 21-22. I agree that's #58554 is talking about solving exactly the same problem, but i don't really like that approach that issue is suggesting.
eddyb commentedon Jan 19, 2020
@crlf0710 I don't understand why you would want to see anything above 12, it's all predictable panic machinery (which happens to be on the stack when the backtrace is produced, and I believe that's what #58554 is focusing on).
There's also not much interesting below 12, either, in that case it's predictable (maybe
stdcould track the stack pointer just before callingmain, and take that into account when obtaining backtraces?)crlf0710 commentedon Jan 19, 2020
@eddyb I'm not insisting on seeing any specific frame. In the above very simple example, i think it's very fine to omit most of the frames.
Actually what i'm trying to say is that, we want to filter these out not because they're at the start and end of the frame, but they're actually implementation details of the rust runtime. Other people, when writing rust framework or runtime system, will likely want to hide their implementation details, too. People will not only want to hide implementation detail of "main" and "panic"(which correspond to the start of stack and end of stack), but also async runtime executors, iterator combinator forwardings, trait object shim functions, drop functions and so on. I am seeking for something more extensible than #58554 here, but it doesn't have to rush to be opened to surface users.