Skip to content
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

regression: panic! and RUST_BACKTRACE=1 Show Wrong & Non-Informative Function Names when Unwinding #78713

Open
DK26 opened this issue Nov 3, 2020 · 19 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. E-help-wanted Call for participation: Help is requested to fix this issue. O-windows Operating system: Windows O-windows-msvc Toolchain: MSVC, Operating system: Windows P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@DK26
Copy link

DK26 commented Nov 3, 2020

As I'm learning the language from a book ("The Complete Rust Programming Reference Guide" p. 229-230), and was executing the panic! macro in a multi-thread environment, I've noticed the unwinding from the book is different from the one I've got where the one I've got is not informative or helpful, and seems wrong where the one in book seems to be OK.

Code

I tried this code:

// panic_unwinding.rs

use std::thread;

fn alice() -> thread::JoinHandle<()> {
    thread::spawn(move || {
        bob();
    })
}

fn bob() {
    malice();
}

fn malice() {
    panic!("malice is panicking!");
}

fn main() {

    let child = alice();
    let _ = child.join();

    bob();
    println!("This is unreachable code");
    
}

I expected the backtrace to include the function names as they were called, all the way from the entry point of the threads.

Instead, all functions were named the same:
(env: RUST_BACKTRACE=1)

thread '<unnamed>' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Version it worked on

I don't know from when is the regression. The book is using an old version of Rust: 1.32.0

Version with regression

I use the most current version: Rust 1.47.0

rustc --version --verbose:

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-pc-windows-msvc
release: 1.47.0
LLVM version: 11.0

@DK26 DK26 changed the title panic! and RUST_BACKTRACE=1 Show Wrong & Non-Informative Function Names when Unwinding regression: panic! and RUST_BACKTRACE=1 Show Wrong & Non-Informative Function Names when Unwinding Nov 3, 2020
@camelid camelid added the A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows label Nov 3, 2020
@jyn514 jyn514 added C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 4, 2020
@ghost
Copy link

ghost commented Nov 8, 2020

Simply testing the example code as provided I find,

thread '<unnamed>' panicked at 'malice is panicking', src/main.rs:14:5
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497
   1: test_crate::malice
             at ./src/main.rs:14
   2: test_crate::bob
             at ./src/main.rs:10
   3: test_crate::alice::{{closure}}
             at ./src/main.rs:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking', src/main.rs:14:5
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497
   1: test_crate::malice
             at ./src/main.rs:14
   2: test_crate::bob
             at ./src/main.rs:10
   3: test_crate::main
             at ./src/main.rs:21
   4: core::ops::function::FnOnce::call_once
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

, under,

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0

, so this might be restricted to O-windows or is that already known?

@camelid camelid added the regression-from-stable-to-stable Performance or correctness regression from one stable version to another. label Apr 29, 2021
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Apr 29, 2021
@apiraino
Copy link
Contributor

apiraino commented May 5, 2021

Bisected to nightly-2020-08-09

found 13 bors merge commits in the specified range
  commit[0] 2020-08-07UTC: Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures, r=lcnr
  commit[1] 2020-08-07UTC: Auto merge of #75071 - ssomers:btree_cleanup_5, r=Mark-Simulacrum
  commit[2] 2020-08-08UTC: Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame, r=Mark-Simulacrum
  commit[3] 2020-08-08UTC: Auto merge of #74877 - lcnr:min_const_generics, r=oli-obk
  commit[4] 2020-08-08UTC: Auto merge of #75276 - JohnTitor:rollup-rz4hs0w, r=JohnTitor
  commit[5] 2020-08-08UTC: Auto merge of #74932 - nnethercote:rm-ast-session-globals, r=petrochenkov
  commit[6] 2020-08-08UTC: Auto merge of #75257 - ssomers:btree_74762_again, r=Mark-Simulacrum
  commit[7] 2020-08-08UTC: Auto merge of #75282 - RalfJung:miri-black-box, r=oli-obk
  commit[8] 2020-08-08UTC: Auto merge of #74289 - lzutao:unroll, r=LukasKalbertodt
  commit[9] 2020-08-08UTC: Auto merge of #74533 - nikic:issue-74425, r=eddyb
  commit[10] 2020-08-08UTC: Auto merge of #75260 - davidtwco:polymorphization-promoted-substs, r=lcnr
  commit[11] 2020-08-08UTC: Auto merge of #75163 - canova:map_into_keys_values, r=dtolnay
  commit[12] 2020-08-08UTC: Auto merge of #75271 - cuviper:array-iter, r=LukasKalbertodt
ERROR: no commits between 09f4c9f5082f78b0adcee83d3ab4337e000cd28e and 
    ceedf1d5febd65b012b8bcd513d70a0a6a091210 within last 167 days

(if I've done correctly), bisected with script:

$ RUST_SRC_REPO=~/rust cargo-bisect-rustc --preserve --start=2020-06-01 --end=2020-10-08 --script=./test.sh

$ cat ./test.sh
#!/bin/sh
RUST_BACKTRACE=1 cargo run 2>&1 | grep __libc_start_main

@apiraino
Copy link
Contributor

apiraino commented May 6, 2021

Assigning priority as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

@rustbot label -I-prioritize +P-medium

@rustbot rustbot added P-medium Medium priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels May 6, 2021
@eggyal
Copy link
Contributor

eggyal commented May 6, 2021

I think #75048 was the likely culprit.

@eggyal
Copy link
Contributor

eggyal commented May 6, 2021

Is the backtrace correctly described with RUST_BACKTRACE=full?

@apiraino
Copy link
Contributor

apiraino commented May 6, 2021

Is the backtrace correctly described with RUST_BACKTRACE=full?

@eggyal In my local test with RUST_BACKTRACE=full seems to print the full stacktrace as expected.
(I don't have access to the reference mentioned by the issue reporter so I cannot compare)

@m-ou-se
Copy link
Member

m-ou-se commented Jul 28, 2021

Has this issue been fixed?

@LukasKalbertodt
Copy link
Member

The issue still occurs with 1.54 on Windows.

C:\Users\lukas>rustc +1.47.0 panic_unwinding.rs

C:\Users\lukas>set RUST_BACKTRACE=1

C:\Users\lukas>panic_unwinding.exe
thread '<unnamed>' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

C:\Users\lukas>rustc +1.54.0 panic_unwinding.rs

C:\Users\lukas>panic_unwinding.exe
thread '<unnamed>' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

@m-ou-se
Copy link
Member

m-ou-se commented Aug 4, 2021

Thanks for testing it! Marking this as a Windows issue. I've tested it on both Linux and Mac, where it works fine.

@m-ou-se m-ou-se added O-windows Operating system: Windows O-windows-msvc Toolchain: MSVC, Operating system: Windows labels Aug 4, 2021
@m-ou-se
Copy link
Member

m-ou-se commented Aug 4, 2021

It also works fine on x86_64-pc-windows-gnu in wine.

@m-ou-se m-ou-se added E-help-wanted Call for participation: Help is requested to fix this issue. and removed regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Oct 6, 2021
@semicoleon
Copy link
Contributor

I can still reproduce this on 1.61.0 but with a weird caveat I haven't seen mentioned anywhere: it works correctly through cargo but not rustc directly?

cargo

>cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target\debug\windows-panic-trace.exe`
thread '<unnamed>' panicked at 'malice is panicking!', src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616
   1: windows_panic_trace::malice
             at .\src\main.rs:16
   2: windows_panic_trace::bob
             at .\src\main.rs:12
   3: windows_panic_trace::alice::closure$0
             at .\src\main.rs:7
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616
   1: windows_panic_trace::malice
             at .\src\main.rs:16
   2: windows_panic_trace::bob
             at .\src\main.rs:12
   3: windows_panic_trace::main
             at .\src\main.rs:23
   4: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\core\src\ops\function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `target\debug\windows-panic-trace.exe` (exit code: 101)

rustc

> rustc .\src\main.rs
> .\main.exe
thread '<unnamed>' panicked at 'malice is panicking!', .\src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: main::alice::{{closure}}
   2: main::alice::{{closure}}
   3: main::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', .\src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: main::alice::{{closure}}
   2: main::alice::{{closure}}
   3: main::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Also RUST_BACKTRACE=full does not seem to resolve the problem

@eggyal
Copy link
Contributor

eggyal commented May 22, 2022

it works correctly through cargo but not rustc directly?

> rustc .\src\main.rs

If you don't specify -C debuginfo, it defaults to 0 (no debug info). cargo's default dev profile uses debuginfo=2 (full debug info). That's the likely difference.

@semicoleon
Copy link
Contributor

Yup, that did the trick

> rustc -C debuginfo=2 .\src\main.rs
> .\main.exe
thread '<unnamed>' panicked at 'malice is panicking!', .\src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616
   1: main::malice
             at .\src\main.rs:16
   2: main::bob
             at .\src\main.rs:12
   3: main::alice::closure$0
             at .\src\main.rs:7
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', .\src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616
   1: main::malice
             at .\src\main.rs:16
   2: main::bob
             at .\src\main.rs:12
   3: main::main
             at .\src\main.rs:23
   4: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\core\src\ops\function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

@ChrisDenton
Copy link
Contributor

So to confirm, this is considered fixed? Or do we still need to handle the debuginfo=0 situation better?

@ChrisDenton ChrisDenton added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Jul 1, 2023
@ChrisDenton
Copy link
Contributor

This still happens unless -C debuginfo is set to 1 or higher (which cargo's dev profile will do by default).

@wesleywiser suggests that:

We should perhaps consider adjusting the default compiler behavior to include basic debuginfo unless the user specifically asks for none

@joshtriplett
Copy link
Member

@ChrisDenton Do you mean for the release profile? I don't think we should be adding any debuginfo to release builds unless the user requests that.

@ChrisDenton
Copy link
Contributor

I don't personally have a strong opinion here tbh but I think that was what @wesleywiser was saying. I could be mistaken though.

@ChrisDenton
Copy link
Contributor

Ok, just to clarify the issue here. When using debuginfo=0 no new debuginfo is created but the prebuilt std does include debuginfo so a pdb file is created anyway.

Something about this seems to confuse the backtrace. Our backtrace-rs defers to dbghelp.dll so this is probably either a bug in the compiler or in dbghelp.dll. It could also be a problem with the way backtrace-rs uses dbghelp.dll.

Here's a demo of the issue. The debuginfo=0 seems to get messed up when not in std functions.

> cat panic.rs
fn main() {
    panic!("Oh no!");
}
debuginfo=0, strip=debuginfo
> rustc +nightly panic.rs -C debuginfo=0 -C strip=debuginfo && ./panic
thread 'main' panicked at 'Oh no!', panic.rs:2:5
stack backtrace:
   0:     0x7ff661d7773c - <unknown>
   1:     0x7ff661d8626b - <unknown>
   2:     0x7ff661d759a1 - <unknown>
   3:     0x7ff661d774eb - <unknown>
   4:     0x7ff661d7953a - <unknown>
   5:     0x7ff661d7918f - <unknown>
   6:     0x7ff661d79bee - <unknown>
   7:     0x7ff661d71181 - <unknown>
   8:     0x7ff661d71059 - <unknown>
   9:     0x7ff661d710ff - <unknown>
  10:     0x7ff661d7169c - <unknown>
  11:     0x7ff661d71226 - <unknown>
  12:     0x7ff661d71069 - <unknown>
  13:     0x7ff661d710bc - <unknown>
  14:     0x7ff661d73918 - <unknown>
  15:     0x7ff661d71097 - <unknown>
  16:     0x7ff661d716b9 - <unknown>
  17:     0x7ff661d89c00 - <unknown>
  18:     0x7ffbe5c926ad - BaseThreadInitThunk
  19:     0x7ffbe69caa68 - RtlUserThreadStart
debuginfo=0
> rustc +nightly panic.rs -C debuginfo=0 && ./panic
thread 'main' panicked at 'Oh no!', panic.rs:2:5
stack backtrace:
   0:     0x7ff74631773c - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:44
   1:     0x7ff74632626b - core::fmt::rt::Argument::fmt
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\rt.rs:138
   2:     0x7ff74632626b - core::fmt::write
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\mod.rs:1094
   3:     0x7ff7463159a1 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\io\mod.rs:1714
   4:     0x7ff7463174eb - std::sys_common::backtrace::_print
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:47
   5:     0x7ff7463174eb - std::sys_common::backtrace::print
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:34
   6:     0x7ff74631953a - std::panicking::default_hook::closure$1
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:269
   7:     0x7ff74631918f - std::panicking::default_hook
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:288
   8:     0x7ff746319bee - std::panicking::rust_panic_with_hook
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:705
   9:     0x7ff746311181 - std::rt::lang_start::hd50dd812db788f81
  10:     0x7ff746311059 - __ImageBase
  11:     0x7ff7463110ff - std::rt::lang_start::hd50dd812db788f81
  12:     0x7ff74631169c - std::rt::lang_start::hd50dd812db788f81
  13:     0x7ff746311226 - std::rt::lang_start::hd50dd812db788f81
  14:     0x7ff746311069 - __ImageBase
  15:     0x7ff7463110bc - std::rt::lang_start::hd50dd812db788f81
  16:     0x7ff746313918 - std::rt::lang_start_internal::closure$2
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148
  17:     0x7ff746313918 - std::panicking::try::do_call
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:500
  18:     0x7ff746313918 - std::panicking::try
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:464
  19:     0x7ff746313918 - std::panic::catch_unwind
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panic.rs:142
  20:     0x7ff746313918 - std::rt::lang_start_internal
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148
  21:     0x7ff746311097 - std::rt::lang_start::hd50dd812db788f81
  22:     0x7ff7463116b9 - main
  23:     0x7ff746329c00 - invoke_main
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  24:     0x7ff746329c00 - __scrt_common_main_seh
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  25:     0x7ffbe5c926ad - BaseThreadInitThunk
  26:     0x7ffbe69caa68 - RtlUserThreadStart
debuginfo=1
> rustc +nightly panic.rs -C debuginfo=1 && ./panic
thread 'main' panicked at 'Oh no!', panic.rs:2:5
stack backtrace:
   0:     0x7ff6014a773c - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:44
   1:     0x7ff6014b626b - core::fmt::rt::Argument::fmt
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\rt.rs:138
   2:     0x7ff6014b626b - core::fmt::write
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\mod.rs:1094
   3:     0x7ff6014a59a1 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\io\mod.rs:1714
   4:     0x7ff6014a74eb - std::sys_common::backtrace::_print
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:47
   5:     0x7ff6014a74eb - std::sys_common::backtrace::print
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:34
   6:     0x7ff6014a953a - std::panicking::default_hook::closure$1
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:269
   7:     0x7ff6014a918f - std::panicking::default_hook
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:288
   8:     0x7ff6014a9bee - std::panicking::rust_panic_with_hook
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:705
   9:     0x7ff6014a1181 - std::panicking::begin_panic::closure$0<ref$<str$> >
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\panicking.rs:626
  10:     0x7ff6014a1059 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic::closure_env$0<ref$<str$> >,never$>
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:151
  11:     0x7ff6014a1059 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic::closure_env$0<ref$<str$> >,never$>
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:151
  12:     0x7ff6014a10ff - std::panicking::begin_panic<ref$<str$> >
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\panicking.rs:625
  13:     0x7ff6014a169c - panic::main
                               at Z:\test\panic.rs:2
  14:     0x7ff6014a1226 - core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\core\src\ops\function.rs:250
  15:     0x7ff6014a1069 - std::sys_common::backtrace::__rust_begin_short_backtrace<void (*)(),tuple$<> >
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:135
  16:     0x7ff6014a1069 - std::sys_common::backtrace::__rust_begin_short_backtrace<void (*)(),tuple$<> >
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:135
  17:     0x7ff6014a10bc - std::rt::lang_start::closure$0<tuple$<> >
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\rt.rs:166
  18:     0x7ff6014a3918 - std::rt::lang_start_internal::closure$2
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148
  19:     0x7ff6014a3918 - std::panicking::try::do_call
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:500
  20:     0x7ff6014a3918 - std::panicking::try
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:464
  21:     0x7ff6014a3918 - std::panic::catch_unwind
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panic.rs:142
  22:     0x7ff6014a3918 - std::rt::lang_start_internal
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148
  23:     0x7ff6014a1097 - std::rt::lang_start<tuple$<> >
                               at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\rt.rs:165
  24:     0x7ff6014a16b9 - main
  25:     0x7ff6014b9c00 - invoke_main
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  26:     0x7ff6014b9c00 - __scrt_common_main_seh
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  27:     0x7ffbe5c926ad - BaseThreadInitThunk
  28:     0x7ffbe69caa68 - RtlUserThreadStart

@ChrisDenton ChrisDenton added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 16, 2023
@ChrisDenton
Copy link
Contributor

Add the T-compiler tag in case they want to look at this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. E-help-wanted Call for participation: Help is requested to fix this issue. O-windows Operating system: Windows O-windows-msvc Toolchain: MSVC, Operating system: Windows P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests