-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Simplified backtraces #12305
Simplified backtraces #12305
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm against expanding bevy_utils with more things when it's become such a common dependency within the dep tree. If anything, bevy_tasks is probably where this should go since that's where our top-level catch_unwind calls are.
Yeah, I only put it into |
Could you please ensure this is optional, I have my own panic handler =) |
I've done some investigation and changed this to no longer require a custom panic hook. It just inserts an extra entry into the call stack. This also means it's just a change in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new outputs are blissfully simple. This has grated on me since the very beginning and I'm guessing others feel the same way. Thanks!
This impl seems reasonable and nicely scoped. Worth considering something in bevy_tasks, but I see no reason not to include this as-is right now as it solves the majority of real-world cases in a nice way.
Now that |
In the first iteration when this was a panic handler this was the plan, but as it's now it's just a special function name. Because this doesn't interfere with anything, it's always on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Today I learned that __rust_begin_short_backtrace
works generically in stable Rust.
This is 100% relying on unstable behavior, but the UX improvement is really compelling. Worst case they change it and all the garbage in the callstack becomes visible again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good! I think it could use a few more comments, probably also links to how Rust formats call stacks, but I won't block on it.
👍
What does the backtraces look like when there's a panic in the render world? |
They're still not great. diff --git a/crates/bevy_render/src/lib.rs b/crates/bevy_render/src/lib.rs
index d972356b0..c4e682d42 100644
--- a/crates/bevy_render/src/lib.rs
+++ b/crates/bevy_render/src/lib.rs
@@ -438,6 +438,7 @@ unsafe fn initialize_render_app(app: &mut App) {
)
.in_set(RenderSet::Render),
World::clear_entities.in_set(RenderSet::Cleanup),
+ || panic!("Render world panic!"),
),
); |
Yeah, the original panic in the rendering thread gets shortened successfully, but the panic at
is still the same since it doesn't happen inside a system. That second panic doesn't add any useful information, but we don't just want to call |
Is there any way we can skip printing the second panic? |
Unless we manipulate it using |
Changed it so that a render world panic causes an Is there a way around that? Otherwise I'm not sure if that change is worth it. |
Perhaps |
Objective
Remove Bevy internals from backtraces
Solution
Executors insert
__rust_begin_short_backtrace
into the callstack before running a system.Example current output
Example output with this PR
Full backtraces (
RUST_BACKTRACE=full
) are unchanged.Alternative solutions
Write a custom panic hook. This could potentially let use exclude a few more callstack frames but requires a dependency on
backtrace
and is incompatible with user-provided panic hooks.Changelog
RUST_BACKTRACE=full
is used)