Missing stack trace on Windows

[parkovski]

This unfortunately is not reliably reproducible - I can get a stack trace from small test projects, so the only way I can demonstrate it is cloning this repo and running (with RUST_BACKTRACE=1) scifiweb.exe run vm/test/noresolve.scifi. I have VS2017 on Windows 10 - I don't remember this happening with 2015, so I'm not sure if it's a change made in VS or Rust.

The error I get is this - there is nothing printed after stack backtrace:.

thread 'main' panicked at 'Can't take immutable awake borrow while mutable borrow is active', util\src\graph_cell.rs:19:4
stack backtrace:

The VS debugger does show a stack trace, so the PDB must be generated correctly.

I'm willing to work on a fix for this if someone can point me toward how to debug the stack trace generation code in Rust.

[parkovski]

I rewrote this code here with more error info, and it works most of the time. Mysteriously, it occasionally fails to find dbghelp.dll. I'm also using the copy from the latest SDK - MSDN says the system copy may not handle all PDBs - frustrating.

[Michael-F-Bryan]

I was trying to debug a failing test at work and noticed there was no backtrace. I believe the reason the OP couldn't reproduce the issue is because it only manifests when a panic occurs in a lower level crate (in our case, some debug_assert!() consistency checks).

$ rustc --version
rustc 1.23.0 (766bd11c8 2018-01-01)
$ cargo --version
cargo 0.24.0 (45043115c 2017-12-05)

[Kleptine]

Just hit this bug on an Option unwrap.

thread 'no_conflicts' panicked at 'called `Option::unwrap()` on a `None` value', libcore\option.rs:355:21
stack backtrace:


failures:
    no_conflicts

[hrydgard]

Also just hit this one, on a Result expect().

thread 'main' panicked at 'my error message', src\libcore\option.rs:1038:5
stack backtrace:
error: process didn't exit successfully: `<my exe>` (exit code: 101)

[pnkfelix]

@michaelwoerister or @wesleywiser , can one of you look into whether you are able to reproduce this yourself? If so, then we can look into root causing it, and potential next steps...

[stefnotch]

For the record, I thought I ran into this, until I realised that #![windows_subsystem = "windows"] hides all output. Including error output.