-
Notifications
You must be signed in to change notification settings - Fork 250
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
clarify interaction between panic = abort
and backtrace capture
#397
Comments
Hm can you clarify what the default here is? Do you mean that libstd's own backtrace printing prints a full backtrace but this crate doesn't print a backtrace at all? (when the two are "called" from the same context). I think that panic=abort vs panic=unwind can affect codegen and it may be affecting unwind tables as well. I'm not 100% certain about that though, and it wouldn't explain the difference in this crate vs libstd. A bit of a long shot, but would it be possible to get some source code I could poke around? |
Hm scratch that
in this repository on macOS prints nothing for this crate itself, but libstd prints a backtrace for the panic! I'm perplexed and something weird is going on here, I'll get back to you after investigating! |
@alexcrichton some background I know that the default panic hook from And yea, here's my simple example program fn main() {
frame1();
}
fn frame1() {
frame2();
}
fn frame2() {
std::env::set_var("RUST_BACKTRACE", "full");
let backtrace = backtrace::Backtrace::new();
eprintln!("Backtrace:\n{:?}", backtrace);
panic!("foo");
} And the output I get in
vs
|
Some quick investigation (heading out now, will dig in more later), is that this is related to how the library that generates the backtrace is itself compiled. In your code, for example, the
(substituting the right target) I think that you'll see that libstd can't generate a backtrace either (or at least that's what I get locally). This makes me think that if the request to unwind comes from code compiled with It looks though like you're getting different output than I am for effectively the same example. You're on Linux, right? |
yea, but this is using stable and I'm not setting that edit: I see you were using stable before too... |
Just some clarification so I can keep up. "request to unwind", is the backtrace capture requesting an unwind? What does requesting an unwind mean? Is it actually unwinding? |
Oh sorry so to clarify Using your example program from above this is what I get:
|
Oh okay, that makes a lot of sense, and a |
Oh I'm happy to provide advice/help/review, but unfortunately I don't have time to implement this myself. Feel free to take it on if you'd like! |
Could we always have the unwind tables, but just omit the landingpads when using |
totally understandable. And yea, if you could write up some instructions on where to start and what the steps would be that would help a lot, and I'll be able to start on this right away. |
Sure yeah! It looks like there's a custom-target-spec option called |
@rustbot modify labels +easy +good-first-issue +project-error-handling |
Error: This repository is not enabled to use triagebot. Please let |
This option exists! |
oh my goddd tylerrrrr ❤️ |
Oh wow, thanks @tmandry for pointing that out! I completely forgot that existed... I think that this issue may be mostly done in that case? Although it may be good to perhaps document that in the crate somewhere? |
Just wanted to go ahead and confirm that this worked for me, after enabling
instead of the original
|
Following the discussion in #397 seems like this is a missing section of the documentation! It seems worthwhile to document some pitfalls and mitigations if possible.
I've tried to add some documentation for this in #407 |
awesome, I was thinking we might also want to add a note about |
Seems reasonable to me! |
* Document unwinding limitations Following the discussion in #397 seems like this is a missing section of the documentation! It seems worthwhile to document some pitfalls and mitigations if possible. * Update split-debuginfo support to nightly
Hello, this flag does not seem to work in release mode. The unwind table is there by default in debug but never in release even with the force unwind tables flag set to yes: Cargo.toml
.cargo/config
Then inspecting my binary there is not RUNTIME_FUNCTION entry, which would be expected if the unwind table was generated. This unwind table is strictly necessary for the binary interface i'm interacting with, are there any other techniques to force this table to generate, i only need an entry for one function in particular? |
any way to put this in like... Cargo.toml or .cargo/config.toml? |
You can put it in the |
for anybody following along [build]
rustflags = ["-C", "force-unwind-tables"] |
The `backtrace` crate isn't compatible with `panic="abort"` (see [docs](https://docs.rs/backtrace/latest/backtrace/) and [issue](rust-lang/backtrace-rs#397)). One great feature we have in egui is pressing down all modifier keys on your keyboard and seeing the backtrace to the widget you hover. This is awesome for when you want to change the code for some specific part of the UI. But it didn't work, at least not always. This PR fixes it. We still use `panic="abort"` in release builds, for the benefit of smaller binaries. * See also emilk/egui#4696
The `backtrace` crate isn't compatible with `panic="abort"` (see [docs](https://docs.rs/backtrace/latest/backtrace/) and [issue](rust-lang/backtrace-rs#397)). One great feature we have in egui is pressing down all modifier keys on your keyboard and seeing the backtrace to the widget you hover. This is awesome for when you want to change the code for some specific part of the UI. But it didn't work, at least not always. This PR fixes it. We still use `panic="abort"` in release builds, for the benefit of smaller binaries. * See also emilk/egui#4696 https://github.com/rerun-io/rerun/assets/1148717/cff9ddbe-838c-4e67-937a-e7dd97d1537f ### Checklist * [x] I have read and agree to [Contributor Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md) * [x] I've included a screenshot or gif (if applicable) * [x] I have tested the web demo (if applicable): * Using examples from latest `main` build: [rerun.io/viewer](https://rerun.io/viewer/pr/6608?manifest_url=https://app.rerun.io/version/main/examples_manifest.json) * Using full set of examples from `nightly` build: [rerun.io/viewer](https://rerun.io/viewer/pr/6608?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG * [x] If applicable, add a new check to the [release checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)! - [PR Build Summary](https://build.rerun.io/pr/6608) - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html) To run all checks from `main`, comment on the PR with `@rerun-bot full-check`.
In our project at work we've been seeing issues with backtrace's not capturing the full context of the application state when we panic, where as the builtin backtrace printer for the default provided panic hook has no such issues.
ZcashFoundation/zebra#1471 shows an example of a backtrace that gets cut off, it only shows the frames pushed onto the stack after calling
expect
, but doesn't include any of our application code's frames otherwise, where as the metadata of the issue captured the location the panic was created from via#[track_caller]
just fine.I'm not convinced I understand what is going on here, or whether this is a bug or expected behaviour, disabling
panic = abort
fixes the issue though, at least in the playground.The text was updated successfully, but these errors were encountered: