-
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
The backtrace printed by assert_eq is wrong with panic=abort #111816
Comments
The outputs of In the case of program with 14: 0x557cb61f2ed3 - core::panicking::panic_fmt::hf33a1475b4dc5c3e In case of program with 14: 0x5562f5589ed3 - core::panicking::panic_fmt::hf33a1475b4dc5c3e It appears that Below is a short read of when to use Cpanic=abort versus Cpanic=unwind and also using build time information for the same. Unwinding the Stack or Aborting in Response to a Panic By default, when a panic occurs, the program starts unwinding, which means Rust walks back up the stack and cleans up the data from each function it encounters. However, this walking back and cleanup is a lot of work. Rust, therefore, allows you to choose the alternative of immediately aborting, which ends the program without cleaning up. Memory that the program was using will then need to be cleaned up by the operating system. If in your project you need to make the resulting binary as small as possible, you can switch from unwinding to aborting upon a panic by adding panic = 'abort' to the appropriate [profile] sections in your Cargo.toml file. For example, if you want to abort on panic in release mode, add this: [profile.release] |
Your post and the documentation you link is about the difference between unwinding and aborting. This is not what this bug report is about. This bug report is about the backtrace that is printed when a panic occurs. The program prints the backtrace before unwinding/aborting. |
With little testing I've found out that this is a regression between The command I've used is
|
@e00E I was only indicating that the observation of stack frames seemed the opposite, for the comparison between assert_eq( ) and |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
You need to pass |
#94815 related to enabling |
stable-x86_64-unknown-linux-gnu
rustc 1.69.0 (84c898d 2023-04-16
Consider the following rust program:
This program panics. The call stack at the panic is
bar <- foo <- main
.I am going to run this program while varying the
-Cpanic
argument like so:With
-Cpanic=unwind
:With
-Cpanic=abort
:Now I am going to change the
assert_eq
toassert
:With
-Cpanic=unwind
:With
-Cpanic=abort
:The part of the backtrace that is meaningful is the
bar <- foo <- main
relation. This part was found in all configurations except when using-Cpanic=abort
withassert_eq
. This is a bug because as evidenced by the other backtraces,main
,foo
, andbar
are part of the call stack at this point. Yet they are not printed. Even when accepting that asserts might print incorrect backtraces in an abort configuration (which I don't), it is still separately unexpected that the backtrace is only incorrect withassert_eq
but not withassert
.The text was updated successfully, but these errors were encountered: