-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Short backtrace have regressed #47429
Comments
#45637 contains a fix for this |
Now being worked on in #47824 instead afaict? |
@jonhoo It is. |
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest:
and after setting that, also claim that:
even though no details were omitted at all (which is the issue of course) |
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found.. |
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much! |
Awesome! I'm happy to see this finally fixed :D |
This frame was added for the exact purpose of allowing proper filtering: rust-lang/rust#47429
This frame was added for the exact purpose of allowing proper filtering: rust-lang/rust#47429
This frame was added for the exact purpose of allowing proper filtering: rust-lang/rust#47429
1
v.s.full
is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed,src/libstd/sys_common/backtrace.rs
contains some code that looks for a__rust_begin_short_backtrace
symbol on the stack to find out what to filter. It looks like some functionality has regressed.Stepping through the program in gdb it looks like the
__rust_begin_short_backtrace
function is called, but despite#[inline(never)]
there’s apparently no stack frame (anymore?) for it.CC @Yamakaky and @alexcrichton for #41815, #38165, and #40264.
The text was updated successfully, but these errors were encountered: