-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Double panic on MSVC no longer prints abort message #123470
Comments
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
Built with the current toolchain:
Then running the executable produces:
Exit code is SIGABRT (134) so there is an abort at lines 5 & 9 of the code but no stack overflow or illegal instructions. I am not sure this is what is expected but it is not as described, this may be a consequence of a difference of OS/environment between the initial report and my system. |
bisects to #110975 raw cargo-bisect-rustc output
@rustbot label: -E-needs-bisection +A-panic |
I tried this code:
I expected to see this happen: I would see a "panic in a destructor during cleanup" message and the program would abort.
Instead, this happened: The second panic prints a full backtrace and then the program exits with
STATUS_STACK_BUFFER_OVERRUN
(that's a__fastfail
; before, it wasSTATUS_ILLEGAL_INSTRUCTION
:intrinsics::abort
instead ofprocess::abort
.)Meta
I didn't bisect to the specific release that changed this, but it's due to the change to allow well-nested unwinds with
catch_unwind
in destructors during cleanup. I also didn't test whether windows-gnu also behaves like this (if it still uses SEH unwinding, it does).rustc 1.56.1 (59eed8a 2021-11-01) output (abort message)
rustc 1.79.0-nightly (8df7e72 2024-03-30) output (no abort message)
full call stack when abort is called, as reported by vscode debugger
@rustbot modify labels: +regression-from-stable-to-stable +O-windows
The text was updated successfully, but these errors were encountered: