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"
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.
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.
Another explody combo: RUSTFLAGS="-Cdebuginfo=2 -Copt-level=3" cargo +system test --no-default-features --features "std unix-backtrace gimli-symbolize" --test smoke
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
(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.
