RUST_BACKTRACE does not work anymore?

[pravic]

I have noticed a backtrace absence on Windows for a while. Stable/Nightly - all the same.

Checked on:

stable-i686-pc-windows-msvc
stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc

update 1: 1.24.1 works fine. How come?
update 2: CARGO_INCREMENTAL=0 has no effect on it.

Linux binaries work as expected, with respect of 0, 1, full values of the RUST_BACKTRACE.

Windows binaries print exactly the same output regardless of environment variable (excluding note):

RUST_BACKTRACE=0:

Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target\debug\stacktrace.exe
thread 'main' panicked at 'called Option::unwrap() on a None value', libcore\option.rs:335:21
note: Run with RUST_BACKTRACE=1 for a backtrace.
error: process didn't exit successfully: target\debug\stacktrace.exe (exit code: 101)

RUST_BACKTRACE=1:

Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target\debug\stacktrace.exe
thread 'main' panicked at 'called Option::unwrap() on a None value', libcore\option.rs:335:21
error: process didn't exit successfully: target\debug\stacktrace.exe (exit code: 101)

Dummy code to reproduce

fn bar() {
  let some: Option<bool> = None;
  some.unwrap();
}

fn foo() {
  bar();
}

fn main() {
  foo(); foo();
}

[pravic]

Interesting. I found at least 2 tests regarding to RUST_BACKTRACE:

https://github.com/rust-lang/rust/blob/master/src/test/run-pass/backtrace.rs
https://github.com/rust-lang/rust/blob/master/src/test/run-pass/backtrace-debuginfo.rs

They are not run on Windows?

[dylanede]

I'm also experiencing this.

[pravic]

Probably #47252 is a culprit.

@alexcrichton I am not sure which team could look on this.

[retep998]

Unable to reproduce on Windows 10. Can everyone please report which version of Windows they're using?

> rustc foo.rs -g; if ($?) { .\foo.exe }
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore\option.rs:335:21
stack backtrace:
   0: std::sys::windows::backtrace::unwind_backtrace
             at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:65
   1: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
   2: std::sys_common::backtrace::print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:59
   3: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:205
   4: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:221
   5: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:457
   6: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:344
   7: std::panicking::rust_begin_panic
             at C:\projects\rust\src\libstd\panicking.rs:322
   8: core::panicking::panic_fmt
             at C:\projects\rust\src\libcore\panicking.rs:71
   9: core::panicking::panic
             at C:\projects\rust\src\libcore\panicking.rs:51
  10: core::option::Option<bool>::unwrap<bool>
             at C:\projects\rust\src\libcore\macros.rs:20
  11: foo::bar
             at .\foo.rs:18
  12: foo::foo
             at .\foo.rs:22
  13: foo::main
             at .\foo.rs:26
  14: std::rt::lang_start::{{closure}}<()>
             at C:\projects\rust\src\libstd\rt.rs:74
  15: std::rt::lang_start_internal::{{closure}}
             at C:\projects\rust\src\libstd\rt.rs:59
  16: std::panicking::try::do_call<closure,i32>
             at C:\projects\rust\src\libstd\panicking.rs:304
  17: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:105
  18: std::panicking::try
             at C:\projects\rust\src\libstd\panicking.rs:283
  19: std::panic::catch_unwind
             at C:\projects\rust\src\libstd\panic.rs:361
  20: std::rt::lang_start_internal
             at C:\projects\rust\src\libstd\rt.rs:58
  21: std::rt::lang_start<()>
             at C:\projects\rust\src\libstd\rt.rs:74
  22: main
  23: invoke_main
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  24: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283
  25: BaseThreadInitThunk
  26: RtlUserThreadStart

> rustc -vV
rustc 1.27.0-nightly (ac3c2288f 2018-04-18)
binary: rustc
commit-hash: ac3c2288f9f9d977acb46406ba60033d65165a7b
commit-date: 2018-04-18
host: x86_64-pc-windows-msvc
release: 1.27.0-nightly
LLVM version: 6.0

[pravic]

Well, sure:

StackWalkEx was introduced in DbgHelp.dll 6.2.

Windows 7 SP1 has dbghelp 6.1.7601 by default. And it is not updated by VS / Tools / Debuggers / whatever. If I manually put a newer dbghelp near an executable, stacktrace prints fine.

So yes, this bug was introduced in #47252. And tests could not catch it, probably, because they are run on Windows 10 or something.

[pravic]

What was the point to use StackWalkEx over StackWalk64, since the former is different only by an additional flag and it is not used anyway?

upd: I see. STACKFRAME_EX gives access to the inline frame context. 😕

[pravic]

cc @Zoxc as the author of the change ✋

[retep998]

So clearly the solution is to add the old StackWalk64 code back but as a fallback in case StackWalkEx cannot be loaded.