Backtraces only showing unknowns on Windows 10

[Jonesey13]

Attempting to run the example in the Chapter "Functions" of the Rust book using RUST_BACKTRACE=1:

fn diverges() -> ! {
    panic!("This function never returns!");
}

fn main() {
    diverges();
}

Under Windows 10 using Rust 1.5 Gnu ABI (64 bit), this gives:

thread '<main>' panicked at 'This function never returns!', hello.rs:2
stack backtrace:
   0:           0x4410a7 - <unknown>
   1:           0x448a5e - <unknown>
   2:           0x40561c - <unknown>
   3:           0x401589 - <unknown>
   4:           0x40151d - <unknown>
   5:           0x4016a8 - <unknown>
   6:           0x4480e8 - <unknown>
   7:           0x4316a1 - <unknown>
   8:           0x447ff7 - <unknown>
   9:           0x4016da - <unknown>
  10:           0x4013b4 - <unknown>
  11:           0x4014e7 - <unknown>
  12:     0x7ffa8ec32d91 - <unknown>

This is a repeat of the issue brought up by user jonas-schievink in Issue #28004 (which was merged).

This issue is also present on the 32bit version and the latest nightly.

[jonas-schievink]

This is a repeat of the issue brought up by user jonas-schievink in Issue #28004 (which was merged).

This should be a duplicate of #28447 then :)

[petrochenkov]

This is essentially a duplicate of #28447 (maybe with a better title)
Some people report that they can't reproduce this, the backtraces also work as expected on the buildbot, so the problem may be specific for Windows >= 8.
(I want to investigate this for a long time, but there always were some more important tasks)

[petrochenkov]

gdb can be used as a workaround for obtaining backtraces

[Jonesey13]

I'm probably doing something wrong but when I run gdb on the executable I get the following:

(gdb) run
Starting program: C:\Users\Jonesey13\projects\rust\RustyHello\hello.exe
[New Thread 10756.0x1e4c]
[New Thread 10756.0x2264]
[New Thread 10756.0x2ce8]
[New Thread 10756.0x8b0]
thread '<main>' panicked at 'This function never returns!', hello.rs:2
[Thread 10756.0x2264 exited with code 101]
[Thread 10756.0x2ce8 exited with code 101]
[Thread 10756.0x8b0 exited with code 101]
[Inferior 1 (process 10756) exited with code 0145]
(gdb) bt
No stack.

[retep998]

To use gdb to obtain backtraces, you have to set a breakpoint somewhere so that gdb can break there and you can get a backtrace. Otherwise the program will panic and exit as normally.

[Jonesey13]

So I guess that means there's currently no way to detect the location of something like

let none: Option<i32> = None;
none.unwrap();

in someone's code using a backtrace atm?

[ranma42]

I think you might try placing a breakpoint on rust_panic. According to the comment https://github.com/rust-lang/rust/blob/master/src/libstd/sys/common/unwind/mod.rs#L171 its main purpose is being a good place for breakpoints that intercept panics.

[Jonesey13]

Thanks for the tip @ranma42! It seems to work correctly:

(gdb) break rust_panic
Breakpoint 1 at 0x43e04a
(gdb) run
Starting program: c:\Users\Jonesey13\Projects\Rust\RustyHello\hello.exe 
[New Thread 2540.0x2118]
warning: FTH: (2540): *** Fault tolerant heap shim applied to current process. This is usually due to previous crashes. ***

[New Thread 2540.0xf64]
[New Thread 2540.0x1a94]
[New Thread 2540.0x23a8]
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore\option.rs:366

Breakpoint 1, 0x000000000043e04a in rust_panic ()
(gdb) bt
#0  0x000000000043e04a in rust_panic ()
#1  0x0000000000405508 in sys_common::unwind::begin_unwind_inner::hd8664d70d0e8892a0ks ()
#2  0x0000000000405c6c in sys_common::unwind::begin_unwind_fmt::h70b08f84bc0aa0aa6js ()
#3  0x000000000043e1a3 in rust_begin_unwind ()
#4  0x00000000004634b9 in panicking::panic_fmt::hd4a3f538cd5921dcZEK ()
#5  0x000000000045d911 in panicking::panic::h11474eb550eeee87wDK ()
#6  0x0000000000401567 in option::_$LT$impl$GT$::unwrap::unwrap::h7269811594158191321 ()
#7  0x000000000040150d in main::h584a48e1b57381e6eaa ()
#8  0x0000000000447fc9 in sys_common::unwind::try::try_fn::h13142058720409824620 ()
#9  0x0000000000431582 in sys_common::unwind::try::inner_try::hd8672c6ed8d8693fyhs ()
#10 0x0000000000447ed8 in rt::lang_start::h2fd7bb830c345727Hix ()
#11 0x00000000004015bb in main ()

[alexcrichton]

Yeah I think this is a dupe of #28447 so I'm going to close in favor of that, thanks for the report though!

[PvdBerg1998]

I just experienced this issue with an executable compiled with Rust Stable (1.21.0) on Win10. The executable was compiled with cargo build --release.