~~~
test [ui] ui/backtrace-debuginfo.rs ... FAILED
test [ui] ui/backtrace.rs ... FAILED
test [ui] ui/std-backtrace.rs ... FAILED
~
In all cases, we are using gdb 9.2 and LLVM 10.
The tests themselves haven't changed since ~1.38, so it must be an actual behavioural change in rustc.
ui/backtrace-debuginfo.rs
~~~~
---- [ui] ui/backtrace-debuginfo.rs stdout ----
executing "/<
------stdout------------------------------
------stderr------------------------------
BISECT: NOT running pass (1) Simplify the CFG on function (_ZN100_$LT$core..slice..Iter$LT$T$GT$$u20$as$u20$core..iter..traits..double_ended..DoubleEndedIterator$GT$9next_back17hba41810a48013369E)
BISECT: NOT running pass (2) SROA on function (_ZN100_$LT$core..slice..Iter$LT$T$GT$$u20$as$u20$core..iter..traits..double_ended..DoubleEndedIterator$GT$9next_back17hba41810a48013369E)
[.. snip ..]
BISECT: NOT running pass (151906) Stack Slot Coloring on function (main)
BISECT: NOT running pass (151907) Machine Copy Propagation Pass on function (main)
BISECT: NOT running pass (151908) Machine Loop Invariant Code Motion on function (main)
BISECT: NOT running pass (151909) PostRA Machine Sink on function (main)
BISECT: NOT running pass (151910) Shrink Wrapping analysis on function (main)
BISECT: NOT running pass (151911) Control Flow Optimizer on function (main)
BISECT: NOT running pass (151912) Tail Duplication on function (main)
BISECT: NOT running pass (151913) Machine Copy Propagation Pass on function (main)
BISECT: NOT running pass (151914) If Converter on function (main)
BISECT: NOT running pass (151915) Branch Probability Basic Block Placement on function (main)
BISECT: NOT running pass (151916) SystemZ Instruction Shortening on function (main)
BISECT: NOT running pass (151917) SystemZ Comparison Elimination on function (main)
BISECT: NOT running pass (151918) PostRA Machine Instruction Scheduler on function (main)
executing "/<
trace does not match position list
still need to find ["backtrace-debuginfo.rs:189", "backtrace-debuginfo.rs:125"]
--- stdout
backtrace-debuginfo.rs:125
backtrace-debuginfo.rs:189
--- stderr
test case 0
thread 'main' panicked at 'explicit panic', /<
stack backtrace:
0: 0x3ff7f781048 -
1: 0x3ff7f898448 - core::fmt::write::h4f1c2070906884a3
2: 0x3ff7f780a02 - std::io::Write::write_fmt::h226b2e1f14ad2764
3: 0x3ff7f7c415e - std::panicking::default_hook::h9ae8480279f42440
4: 0x3ff7f7c4ff8 - std::panicking::rust_panic_with_hook::haa0e4552a4685cd1
5: 0x2aa08f936b6 -
6: 0x2aa08f934ee -
7: 0x2aa08f9e64e -
8: 0x2aa08f9102a -
9: 0x2aa08f91586 -
10: 0x2aa08f920cc -
11: 0x2aa08f93766 -
12: 0x2aa08f9354a -
13: 0x2aa08f93600 -
14: 0x3ff7f7c49e2 - std::panicking::try::do_call::hb8645513a8eb3708
15: 0x3ff7f7c6834 - __rust_try.llvm.10017331706622121556
16: 0x3ff7f7c5520 - std::rt::lang_start_internal::h8d96ae79e52a8f4b
17: 0x2aa08f935ce -
18: 0x2aa08f9216e -
19: 0x3ff7f42b3ce - __libc_start_main
20: 0x2aa08f834f4 -
21: 0x0 -
trace does not match position list
still need to find ["backtrace-debuginfo.rs:189", "backtrace-debuginfo.rs:125"]
--- stdout
backtrace-debuginfo.rs:125
backtrace-debuginfo.rs:189
--- stderr
test case 1
thread 'main' panicked at 'explicit panic', /<
stack backtrace:
0: 0x3ffa0201048 -
1: 0x3ffa0318448 - core::fmt::write::h4f1c2070906884a3
2: 0x3ffa0200a02 - std::io::Write::write_fmt::h226b2e1f14ad2764
3: 0x3ffa024415e - std::panicking::default_hook::h9ae8480279f42440
4: 0x3ffa0244ff8 - std::panicking::rust_panic_with_hook::haa0e4552a4685cd1
5: 0x2aa182136b6 -
6: 0x2aa182134ee -
7: 0x2aa1821e64e -
8: 0x2aa182110c6 -
9: 0x2aa18211586 -
10: 0x2aa182120cc -
11: 0x2aa18213766 -
12: 0x2aa1821354a -
13: 0x2aa18213600 -
14: 0x3ffa02449e2 - std::panicking::try::do_call::hb8645513a8eb3708
15: 0x3ffa0246834 - __rust_try.llvm.10017331706622121556
16: 0x3ffa0245520 - std::rt::lang_start_internal::h8d96ae79e52a8f4b
17: 0x2aa182135ce -
18: 0x2aa1821216e -
19: 0x3ff9feab3ce - __libc_start_main
20: 0x2aa182034f4 -
21: 0x0 -
trace does not match position list
still need to find ["backtrace-debuginfo.rs:189", "backtrace-debuginfo.rs:125", "backtrace-debuginfo.rs:88", "backtrace-debuginfo-aux.rs:6"]
--- stdout
backtrace-debuginfo-aux.rs:6
backtrace-debuginfo.rs:88
backtrace-debuginfo.rs:125
backtrace-debuginfo.rs:189
--- stderr
test case 2
thread 'main' panicked at 'explicit panic', /<
stack backtrace:
0: 0x3ffadb01048 -
1: 0x3ffadc18448 - core::fmt::write::h4f1c2070906884a3
2: 0x3ffadb00a02 - std::io::Write::write_fmt::h226b2e1f14ad2764
3: 0x3ffadb4415e - std::panicking::default_hook::h9ae8480279f42440
4: 0x3ffadb44ff8 - std::panicking::rust_panic_with_hook::haa0e4552a4685cd1
5: 0x2aa366936b6 -
6: 0x2aa366934ee -
7: 0x2aa3669e64e -
8: 0x2aa36693404 -
9: 0x2aa36693340 -
10: 0x2aa36691082 -
11: 0x2aa36691586 -
12: 0x2aa366920cc -
13: 0x2aa36693766 -
14: 0x2aa3669354a -
15: 0x2aa36693600 -
16: 0x3ffadb449e2 - std::panicking::try::do_call::hb8645513a8eb3708
17: 0x3ffadb46834 - __rust_try.llvm.10017331706622121556
18: 0x3ffadb45520 - std::rt::lang_start_internal::h8d96ae79e52a8f4b
19: 0x2aa366935ce -
20: 0x2aa3669216e -
21: 0x3ffad7ab3ce - __libc_start_main
22: 0x2aa366834f4 -
23: 0x0 -
[.. snip .. many more examples like this ..]
thread 'main' panicked at 'found some errors', /<
stack backtrace:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
~~~~
ui/backtrace.rs
~~~~
---- [ui] ui/backtrace.rs stdout ----
executing "/<
------stdout------------------------------
------stderr------------------------------
executing "/<
------stdout------------------------------
------stderr------------------------------
thread 'main' panicked at 'bad output: thread 'main' panicked at 'explicit panic', /<
stack backtrace:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
', /<
stack backtrace:
0: rust_begin_unwind
1: std::panicking::begin_panic_fmt
2:
3:
4:
5: std::panicking::try::do_call
6: __rust_try.llvm.10017331706622121556
7: std::rt::lang_start_internal
8:
9: __libc_start_main
10:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
error: test run failed!
status: exit code: 101
command: "/<
thread 'main' panicked at 'bad output: thread 'main' panicked at 'explicit panic', /<
stack backtrace:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
', /<
stack backtrace:
0: rust_begin_unwind
1: std::panicking::begin_panic_fmt
2:
3:
4:
5: std::panicking::try::do_call
6: __rust_try.llvm.10017331706622121556
7: std::rt::lang_start_internal
8:
9: __libc_start_main
10:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
~~~~
ui/std-backtrace.rs
~~~~
---- [ui] ui/std-backtrace.rs stdout ----
executing "/<
------stdout------------------------------
------stderr------------------------------
executing "/<
------stdout------------------------------
------stderr------------------------------
thread 'main' panicked at 'assertion failed: String::from_utf8_lossy(&p.stdout).contains("backtrace::main")', /<
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
error: test run failed!
status: exit code: 101
command: "/<
thread 'main' panicked at 'assertion failed: String::from_utf8_lossy(&p.stdout).contains("backtrace::main")', /<
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
~~~~
@alexcrichton could this be related to #74682 ?
Seems likely! If this is happening on big-endian platforms then there's likely an issue with endianness in (most likely) src/backtrace/gimli/*.rs. It could also be in gimli itself or addr2line, but it seems most likely to be in the integration in the backtrace crate itself.
Related: #77424
Assigning P-high and removing I-prioritize as discussed in the prioritization working group.
I'll try to run gimli etc things on a sparc, but no promises of success.
I have an s390x machine at hand, so I tried a few things. Plain cargo test passes for gimli, addr2line, and object, but backtrace fails two tests:
Running target/debug/deps/accuracy-18628a8819e01c2c
running 1 test
test doit ... FAILED
failures:
---- doit stdout ----
-----------------------------------
looking for:
tests/accuracy/main.rs:40
crates/dylib-dep/src/lib.rs:11
tests/accuracy/main.rs:39
found:
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: <unknown>
14: <unknown>
15: <unknown>
16: start_thread
17: <unknown>
thread 'doit' panicked at 'failed to find tests/accuracy/main.rs:40', tests/accuracy/main.rs:104:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Running target/debug/deps/smoke-9c443e6c4ee6f0fc
running 3 tests
test smoke_test_frames ... FAILED
test sp_smoke_test ... ok
test many_threads ... test many_threads has been running for over 60 seconds
test many_threads ... ok
failures:
---- smoke_test_frames stdout ----
thread 'smoke_test_frames' panicked at 'assertion failed: !can_resolve', tests/smoke.rs:180:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
There are also warnings about FFI safety, but I don't know if they're relevant.
warning: `extern` fn uses type `(&str, u32)`, which is not FFI-safe
--> crates/dylib-dep/src/lib.rs:10:30
|
10 | pub extern "C" fn foo(outer: Pos, inner: fn(Pos, Pos)) {
| ^^^ not FFI-safe
|
= note: `#[warn(improper_ctypes_definitions)]` on by default
= help: consider using a struct instead
= note: tuples have unspecified layout
warning: `extern` fn uses type `fn((&str, u32), (&str, u32))`, which is not FFI-safe
--> crates/dylib-dep/src/lib.rs:10:42
|
10 | pub extern "C" fn foo(outer: Pos, inner: fn(Pos, Pos)) {
| ^^^^^^^^^^^^ not FFI-safe
|
= help: consider using an `extern fn(...) -> ...` function pointer instead
= note: this function pointer has Rust-specific calling convention
warning: 2 warnings emitted
It may be easier to reproduce on a mac: https://github.com/rust-lang/rust/issues/77424
Mac may have a very different issue, since it's apparently a big-endian thing here.
(Plus I don't have a mac at all. :wink: )
Well, this will do it:
https://github.com/rust-lang/backtrace-rs/blob/2b51e00670927b58255f92f2281367187a49f370/src/symbolize/gimli.rs#L8
use self::gimli::LittleEndian as Endian;
I think this should this be NativeEndian, unless there's support for backtracing other processes.
Side note: does this need to be updated?
Most helpful comment
Mac may have a very different issue, since it's apparently a big-endian thing here.
(Plus I don't have a mac at all. :wink: )