RUST_BACKTRACE=full panic causes infinite loop on aarch64-pc-windows-msvc #123686
Closed
Description
I tried running this code (default cargo new --bin template, changed println! to panic! ):
fn main() {
panic!("Hello, world!");
}It builds fine on a aarch64-pc-windows-msvc host, and runs fine with RUST_BACKTRACE env variable:
- left unset
- set to
0 - set to
1
When I run it (on a aarch64-pc-windows-msvc host) with (RUST_BACKTRACE=full), the panic triggers an infinite loop:
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target\debug\arm_panic_test.exe`
thread 'main' panicked at src\main.rs:2:5:
Hello, world!
stack backtrace:
0: 0x7ff6cb635d24 - std::sys_common::backtrace::_print::impl$0::fmt
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:44
1: 0x7ff6cb6428d4 - core::fmt::rt::Argument::fmt
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\core\src\fmt\rt.rs:142
2: 0x7ff6cb6428d4 - core::fmt::write
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\core\src\fmt\mod.rs:1120
3: 0x7ff6cb634368 - std::io::Write::write_fmt<std::sys::pal::windows::stdio::Stderr>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\io\mod.rs:1846
4: 0x7ff6cb635b70 - std::sys_common::backtrace::_print
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:47
5: 0x7ff6cb635b70 - std::sys_common::backtrace::print
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:34
6: 0x7ff6cb637554 - std::panicking::default_hook::closure$1
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\panicking.rs:272
7: 0x7ff6cb637208 - std::panicking::default_hook
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\panicking.rs:292
8: 0x7ff6cb637a04 - std::panicking::rust_panic_with_hook
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\panicking.rs:781
9: 0x7ff6cb6378a8 - std::panicking::begin_panic_handler::closure$0
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\panicking.rs:651
10: 0x7ff6cb6362e8 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:171
11: 0x7ff6cb6362e8 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:171
12: 0x7ff6cb6362e8 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:171
13: 0x7ff6cb6362e8 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:171
14: 0x7ff6cb6362e8 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:171
15: 0x7ff6cb6362e8 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:171
16: 0x7ff6cb6362e8 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library\std\src\sys_common\backtrace.rs:171
...
... repeated indefinitely until I press CTRL^C
...
This also causes unit test execution to hang (e.g. for tokio) if RUST_BACKTRACE=full and a document test contains ````should_panic`.
rustc --version --verbose:
rustc --version --verbose
rustc 1.77.1 (7cf61ebde 2024-03-27)
binary: rustc
commit-hash: 7cf61ebde7b22796c69757901dd346d0fe70bd97
commit-date: 2024-03-27
host: aarch64-pc-windows-msvc
release: 1.77.1
LLVM version: 17.0.6
Additional Info:
- This appears to be unique to aarch64-pc-windows-msvc.
- The same set of steps runs as expected on
aarch64-apple-darwin. - The same set of steps runs as expected
x86_64-pc-windows-msvc.
- The same set of steps runs as expected on
- If it matters, VS2022 (not VS2019) was installed.
- It is straightforward to reproduce. If you need me to gather additional info, please let me know.
Activity