Bug 710380 – dev-lang/rust-1.41.0 breaks backtrace-0.3.44 test "smoke" with --all-features

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Kent Fredric (IRC: kent\n) (RETIRED) 2020-02-21 08:14:17 UTC]

Created attachment 614812 [details, diff]
Decrufting patch required for --all-features without nightly

Replicating this bug has been a bit fun, for starters, one needs a patch set that strips all the nightly only features.

But after whittling it down:


> RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +system test --all-features --test smoke

Fails

> RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +stable test --all-features --test smoke

Passes.

But this problem *doesnt* happen with any feature in isolation ( --no-default-features --features "foo" ), only with --all-features, so exposing it requires some interaction between features.

And this problem *doesnt* happen with -Copt-level=0 -Cdebuginfo=2

But it *does* happen with -Copt-level=0 -Cdebuginfo=0 


.... But that's not all:

> RUSTFLAGS="-Cdebuginfo=0 -Copt-level=0" cargo +system test --features "default" --test smoke 

Fails.

> RUSTFLAGS="-Cdebuginfo=0 -Copt-level=0" cargo +stable test --features "default" --test smoke 

Fails.


> RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +system test --features "default" --test smoke 

Passes!

> RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +system test --features "default gimli-symbolize" --test smoke

Fails!

> RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +stable test --features "default gimli-symbolize" --test smoke

Passes!

So ... obviously something weird is happening that makes our rustc "different" from official rustc.



RUST_BACKTRACE=1 RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +system test --all-features --test smoke
    Finished test [unoptimized + debuginfo] target(s) in 0.09s
     Running target/debug/deps/smoke-38cd9123d28083f7

running 4 tests
test is_serde ... ok
test is_rustc_serialize ... ok
test smoke_test_frames ... FAILED
test many_threads ... ok

failures:

---- smoke_test_frames stdout ----
symbol  ip:0x55d8cd16ed2b address:0x55d8cd16ed00 name:smoke::smoke_test_frames::frame_4::h7dabf9a2b8a32040 file:/home/kent/.cpanm/work/1582263570.4212/backtrace-0.3.44/tests/smoke.rs lineno:29 
symbol  ip:0x55d8cd179f4f address:0x55d8cd179f10 name:<alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::ha3c0ff7805a0a575 
thread 'smoke_test_frames' panicked at 'didn't find a symbol', src/libcore/option.rs:1188:5
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
   4: std::panicking::default_hook::{{closure}}
   5: std::panicking::default_hook
   6: std::panicking::rust_panic_with_hook
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::option::expect_failed
  10: core::option::Option<T>::expect
             at /var/tmp/portage/dev-lang/rust-1.41.0/work/rustc-1.41.0-src/src/libcore/option.rs:348
  11: smoke::smoke_test_frames::assert_frame
             at tests/smoke.rs:179
  12: smoke::smoke_test_frames::frame_4
             at tests/smoke.rs:68
  13: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  14: __rust_maybe_catch_panic
  15: test::run_test_in_process
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


dev-lang/rust-1.41.0::gentoo was built with the following:
USE="clippy rls rustfmt system-bootstrap wasm -debug -doc -libressl -nightly -parallel-compiler -system-llvm" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" LLVM_TARGETS="BPF NVPTX WebAssembly (X86) -AArch64 -AMDGPU -ARM -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -XCore"

[Comment 1 Kent Fredric (IRC: kent\n) (RETIRED) 2020-02-21 08:48:37 UTC]

Further digging:

If you ignore the effects of the RUSTFLAGS, you can reduce the failure set to this:

> RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +system test --no-default-features --features "std libunwind gimli-symbolize" --test smoke

It doesn't fail if you hand-expand gimli-symbolize, std is a requirement, and it doesn't fail without libunwind.

So looking at the failing test source:

> static LIBUNWIND: bool = cfg!(all(unix, feature = "libunwind"));
> static GIMLI_SYMBOLIZE: bool = cfg!(all(feature = "gimli-symbolize", unix, target_os = "linux"));

But doesn't really explain the issue.

All I can tell is GIMLI_SYMOLIZE being true means the "can_resolve" is true, which means this block is triggering:


        if can_resolve {
            addr.expect("didn't find a symbol");
        }

What bothers me is I can't tell *why* its returning, the loop is setting resolved to 1, ... and then it errors because it worked?! Sorry, I don't grok this logic.

[Comment 2 Georgy Yakovlev 2020-02-21 09:24:38 UTC]

i'm pretty sure it's because compiler/standard lib built without debuginfo.
even some rust tests fail if you compile it without debuginfo.


currently ebuild disabled optimize with USE=debug and it should not, as it produces unusable compiler (25x slower), so we need to set optimize = true no matter if USE=debug or not.


so if you wanna rebuild rust with USE=debug, make use that optimize=true in config.toml

more info here

https://github.com/rust-lang/rust/blob/master/config.toml.example

I'll try a rebuild later.

[Comment 3 Kent Fredric (IRC: kent\n) (RETIRED) 2020-02-21 09:42:05 UTC]

Another explody combo:

RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +system test --no-default-features --features "std unix-backtrace gimli-symbolize" --test smoke

[Comment 4 Georgy Yakovlev 2020-02-22 05:31:48 UTC]

debug rust still fails tests, maybe it's upstream bug?
I see some issues that mention if dynamic libs are used it behaves differently.
rustup installed rust is pretty static.

https://github.com/rust-lang/backtrace-rs/issues/238

[Comment 5 Kent Fredric (IRC: kent\n) (RETIRED) 2020-02-22 17:55:32 UTC]

(In reply to Georgy Yakovlev from comment #4)
> debug rust still fails tests, maybe it's upstream bug?
> I see some issues that mention if dynamic libs are used it behaves
> differently.
> rustup installed rust is pretty static.
> 
> https://github.com/rust-lang/backtrace-rs/issues/238

Hard to say :/

I just wanted to rule out any differences between our rust and upstreams which upstream *could* use as justification to not respond at all to the bug.