No namespaces in backtraces on windows

[nikomatsakis]

The src/test/run-pass/backtrace test exposed a difference in how windows backtraces handle namespacing. Here is what I wrote in a fixme:

    // FIXME(#32481)
    //
    // On windows, we read the function name from debuginfo using some
    // system APIs. For whatever reason, these APIs seem to use the
    // "name" field, which is only the "relative" name, not the full
    // name with namespace info, so we just see `foo` and not
    // `backtrace::foo` as we see on linux (which uses the linkage
    // name).

My hypothesis then is that backtraces on windows never show module information, only the name of the fn which failed. Perhaps @retep998 you can confirm?

cc @michaelwoerister @alexcrichton

[alexcrichton]

Looks like this may randomly get fixed by #34743

[retep998]

Using this code.

mod a {
    pub fn foo() { b::foo() }
    mod b {
        pub fn foo() { c::foo() }
        mod c {
            pub fn foo() { d::foo() }
            mod d {
                pub fn foo() { panic!("Nesting!") }
            }
        }
    }
}
fn main() { a::foo() }

This is the current situation.

test> rustc nested.rs; ./nested.exe
thread 'main' panicked at 'Nesting!', nested.rs:9
stack backtrace:
   0:     0x7ff749049d6c - std::rt::lang_start::hfe4efe1fc39e4a30
   1:     0x7ff749049379 - std::rt::lang_start::hfe4efe1fc39e4a30
   2:     0x7ff7490424fd - std::panicking::rust_panic_with_hook::h983af77c1a2e581b
   3:     0x7ff749041109 - main
   4:     0x7ff74904109d - main
   5:     0x7ff749041068 - main
   6:     0x7ff749041058 - main
   7:     0x7ff749041018 - __ImageBase
   8:     0x7ff749041008 - __ImageBase
   9:     0x7ff749048d6c - std::rt::lang_start::hfe4efe1fc39e4a30
  10:     0x7ff74904cd81 - _rust_maybe_catch_panic
  11:     0x7ff749048aa4 - std::rt::lang_start::hfe4efe1fc39e4a30
  12:     0x7ff749041049 - main
  13:     0x7ff74905073b - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255
  14:     0x7ffa1d228101 - BaseThreadInitThunk

test> rustc -g nested.rs; ./nested.exe
thread 'main' panicked at 'Nesting!', nested.rs:9
stack backtrace:
   0:     0x7ff7338e9ddc - std::rt::lang_start::hfe4efe1fc39e4a30
   1:     0x7ff7338e93e9 - std::rt::lang_start::hfe4efe1fc39e4a30
   2:     0x7ff7338e256d - std::panicking::rust_panic_with_hook::h983af77c1a2e581b
   3:     0x7ff7338e1152 - begin_panic<&str>
                        at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:328
   4:     0x7ff7338e10df - foo
                        at C:\msys64\home\Peter\test\<std macros>:3
   5:     0x7ff7338e109e - foo
                        at C:\msys64\home\Peter\test\nested.rs:7
   6:     0x7ff7338e107e - foo
                        at C:\msys64\home\Peter\test\nested.rs:5
   7:     0x7ff7338e102e - foo
                        at C:\msys64\home\Peter\test\nested.rs:3
   8:     0x7ff7338e100e - main
                        at C:\msys64\home\Peter\test\nested.rs:14
   9:     0x7ff7338e8ddc - std::rt::lang_start::hfe4efe1fc39e4a30
  10:     0x7ff7338ecdf1 - _rust_maybe_catch_panic
  11:     0x7ff7338e8b14 - std::rt::lang_start::hfe4efe1fc39e4a30
  12:     0x7ff7338e1069 - main
  13:     0x7ff7338f07ab - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255
  14:     0x7ffa1d228101 - BaseThreadInitThunk

When that PR lands and gets into nightly, I will post fresh results to confirm what occurs.

[retep998]

The situation has indeed improved. The lack of debuginfo in the std that comes with nightly is still somewhat detrimental though, but namespaces are working.

test> rustc -g nested.rs ; ./nested.exe
thread 'main' panicked at 'Nesting!', nested.rs:8
stack backtrace:
   0:     0x7ff62e26948a - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   1:     0x7ff62e2681b2 - std::rt::lang_start::haaae1186de9de8cb
   2:     0x7ff62e268b5d - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   3:     0x7ff62e2610d7 - std::panicking::begin_panic<&str>
                        at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:383
   4:     0x7ff62e261325 - nested::a::b::c::d::foo
                        at C:\msys64\home\Peter\test\nested.rs:8
   5:     0x7ff62e2612f0 - nested::a::b::c::foo
                        at C:\msys64\home\Peter\test\nested.rs:6
   6:     0x7ff62e2612d0 - nested::a::b::foo
                        at C:\msys64\home\Peter\test\nested.rs:4
   7:     0x7ff62e2612b0 - nested::a::foo
                        at C:\msys64\home\Peter\test\nested.rs:2
   8:     0x7ff62e261340 - nested::main
                        at C:\msys64\home\Peter\test\nested.rs:13
   9:     0x7ff62e26bfb1 - _rust_maybe_catch_panic
  10:     0x7ff62e267bea - std::rt::lang_start::haaae1186de9de8cb
  11:     0x7ff62e261379 - main
  12:     0x7ff62e26fca4 - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  13:     0x7ff964778101 - BaseThreadInitThunk

[petrochenkov]

Yeah, right, improved.

thread 'main' panicked at 'Nesting!', ../../test.rs:8
stack backtrace:
   0:           0x42fb94 - <unknown>
   1:           0x42c4b1 - <unknown>
   2:           0x42cbda - <unknown>
   3:           0x401612 - <unknown>
   4:           0x401855 - <unknown>
   5:           0x401820 - <unknown>
   6:           0x401800 - <unknown>
   7:           0x4017e0 - <unknown>
   8:           0x401870 - <unknown>
   9:           0x42c858 - <unknown>
  10:           0x438238 - <unknown>
  11:           0x42bc53 - <unknown>
  12:           0x4018aa - <unknown>
  13:           0x4013e7 - <unknown>
  14:           0x40151a - <unknown>
  15:     0x7ffeb8dd13d1 - <unknown>

[retep998]

@petrochenkov Which version of Rust are you using? I'm using x86_64-pc-windows-msvc.

With i686-pc-windows-msvc I still get a good backtrace as well.

test> rustc -g nested.rs --target=i686-pc-windows-msvc ; ./nested.exe
thread 'main' panicked at 'Nesting!', nested.rs:8
stack backtrace:
   0:   0xfa788b - std::rt::lang_start::haaae1186de9de8cb
   1:   0xfa810a - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   2:   0xfa10ec - std::panicking::begin_panic<&str>
                at C:\bot\slave\nightly-dist-rustc-win-msvc-32\build\src\libstd\panicking.rs:383
   3:   0xfa12df - nested::a::b::c::d::foo
                at C:\msys64\home\Peter\test\nested.rs:8
   4:   0xfa12a9 - nested::a::b::c::foo
                at C:\msys64\home\Peter\test\nested.rs:6
   5:   0xfa1299 - nested::a::b::foo
                at C:\msys64\home\Peter\test\nested.rs:4
   6:   0xfa1289 - nested::a::foo
                at C:\msys64\home\Peter\test\nested.rs:2
   7:   0xfa12e9 - nested::main
                at C:\msys64\home\Peter\test\nested.rs:13
   8:   0xfaaa7b - __rust_maybe_catch_panic
   9:   0xfa7300 - std::rt::lang_start::haaae1186de9de8cb
  10:   0xfa1310 - main
  11: 0x75e438f3 - BaseThreadInitThunk
  12: 0x77935de2 - RtlUnicodeStringToInteger

[petrochenkov]

GNU

[retep998]

Ah yeah, windows gnu is still broken, but this issue is tracking whether namespaces are properly in the backtrace output, not whether backtraces work at all. Although granted it can be hard to tell whether namespaces are working when you don't get a backtrace. I'd probably close this as solved since namespaces work fine on windows platforms where backtraces do work, and if #33985 ever gets solved and it turns out namespaces don't work in gnu backtraces, then this issue can be reopened.

[vvuk]

This works with -g (msvc build), but without -g it's maybe even worse now:

$ RUST_BACKTRACE=1 ./a
thread 'main' panicked at 'Nesting!', a.rs:1
stack backtrace:
   0:     0x7ff764709994 - std::panicking::default_hook::{{closure}}
                        at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:252
   1:     0x7ff76470841b - std::panicking::default_hook
                        at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:263
   2:     0x7ff764708d1d - std::panicking::rust_panic_with_hook
                        at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\panicking.rs:451
   3:     0x7ff764701094 - CREATE_PROCESS_LOCK
   4:     0x7ff76470125f - CREATE_PROCESS_LOCK
   5:     0x7ff76470122a - CREATE_PROCESS_LOCK
   6:     0x7ff76470120a - CREATE_PROCESS_LOCK
   7:     0x7ff7647011ea - CREATE_PROCESS_LOCK
   8:     0x7ff76470127a - CREATE_PROCESS_LOCK
   9:     0x7ff76470be61 - panic_unwind::__rust_maybe_catch_panic
                        at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libpanic_unwind\lib.rs:97
  10:     0x7ff764707e5a - std::rt::lang_start
                        at C:\bot\slave\nightly-dist-rustc-win-msvc-64\build\src\libstd\rt.rs:51
  11:     0x7ff7647012b9 - main
  12:     0x7ff76470f9d4 - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  13:     0x7ffadc838363 - BaseThreadInitThunk

[vvuk]

(Fixed with -C debuginfo=1 at least)

[Mark-Simulacrum]

I'd probably close this as solved since namespaces work fine on windows platforms where backtraces do work, and if #33985 ever gets solved and it turns out namespaces don't work in gnu backtraces, then this issue can be reopened.

Per the above from this comment, closing. Please reopen if you disagree (or let us know and we can do so).