Stack traces / backtraces in Windows show everything in "main"

[sivadeilra]

When RUST_BACKTRACE=1 is set and a panic occurs on Windows, the stack trace shows everything in main. Example:

thread '<main>' panicked at 'assertion failed: *start <= *end', C:\bot\slave\nightly-win-64\build\src\libcore\slice.rs:459
stack backtrace:
   1:           0x493d28 - main
   2:           0x4a6080 - main
   3:           0x42d718 - main
   4:           0x42dc0c - main
   5:           0x4a587e - main
   6:           0x4bb4bd - main
   7:           0x4b946f - main
   8:           0x40b58f - main
   9:           0x403af7
  10:           0x4a781c - main
  11:           0x4a77f9 - main
  12:           0x4a688a - main
  13:           0x4013b5
  14:           0x4014e8
  15:     0x7fff44c116ad - BaseThreadInitThunk

[retep998]

cc @vadimcn

[tsemple]

I'm having this problem too. It makes rust very difficult to use on Windows because panics take a long time to track down.

I looked into it, and the symbols produced during compile don't seem to be compatible with SymFromAddr(). The exe does has symbols which can be seen with dumpbin and nm. I googled for a while trying to figure out why the symbols are incompatible, but didn't find anything. Maybe someone else understands more about this.

One way to fix this would be to use something other than SymFromAddr() to get the symbol names. I'm not sure how nm works but it seems to have enough information to do the symbol lookups. It also understand the format for the line numbers unlike both dumpbin and SymGetLineFromAddr().

[vadimcn]

The crux of the matter here is that Windows' dbghelp API does not understand DWARF debug info, so it only sees the exported symbols of the module. It then reports all addresses relative to the nearest exported symbol. Of which 'main' is usually the only one in an .exe module, so your whole callstack is reported relative to that. There's also an offset, but Rust's backtrace doesn't print that.
The easiest way to get a backtrace is to start your program under gdb, slap a breakpoint on 'rust_panic', then print a backtrace via 'bt' when it is hit.

[retep998]

The proper solution would be to use PDB debug info, but there's no way to generate PDBs short of depending on components of the MSVC toolchain. Maybe one day LLVM will figure it out when they work on LLD.

[tsemple]

This clang webpage (http://clang.llvm.org/docs/MSVCCompatibility.html)
implies that LLVM can make a pdb with stack trace info if MSVC link.exe is
used. Do you think that would work for rust? I've tried linking with MSVC
link.exe, but wasn't able to fix all the linker errors.

On Sun, Feb 15, 2015 at 6:38 PM, Peter Atashian notifications@github.com
wrote:

The proper solution would be to use PDB debug info, but there's no way to
generate PDBs short of depending on components of the MSVC toolchain. Maybe
one day LLVM will figure it out when they work on LLD.

—
Reply to this email directly or view it on GitHub
#20351 (comment).

[retep998]

Being able to use the MSVC link.exe is something that we want to support eventually, but will take significant effort and time. In the meantime though it would be nice to find a solution for getting backtraces without using GDB.

[vadimcn]

Rust already includes libbacktrace, which can interpret DWARF; however currently it only supports ELF executables. If you feel strongly about this missing feature, you can try to teach it how to find the relevant section in Windows COFFs.

[msiemens]

For what it's worth, Rust produces correct backtraces on Windows – when ICE'ing

[alexcrichton]

I think this is basically fixed by #28004, so closing