RUST_BACKTRACE does not work anymore?

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();
}

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?

I'm also experiencing this.

@alexcrichton

Probably #47252 is a culprit.

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

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

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.

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. 😕

@Zoxc

cc @Zoxc as the author of the change ✋

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

Add a fallback for stacktrace printing for older Windows versions.

Auto merge of #50526 - moxian:just-fix, r=alexcrichton

Navigation Menu

Repository navigation

RUST_BACKTRACE does not work anymore? #50138

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

RUST_BACKTRACE does not work anymore? #50138

Description

Activity

pravic commented on Apr 22, 2018

dylanede commented on Apr 24, 2018

pravic commented on Apr 24, 2018

retep998 commented on Apr 24, 2018

pravic commented on Apr 24, 2018

pravic commented on Apr 24, 2018

pravic commented on Apr 24, 2018

retep998 commented on Apr 24, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions