matthiaskrgr
commented
6 years ago Still crashing with 1.23.0-nightly (aabfed5e0 2017-11-17) and rustfmt @ abe6eec910ee7544edbc8a80167c029190228cac
Open matthiaskrgr opened 6 years ago
matthiaskrgr
commented
6 years ago Still crashing with 1.23.0-nightly (aabfed5e0 2017-11-17) and rustfmt @ abe6eec910ee7544edbc8a80167c029190228cac
matthiaskrgr
commented
6 years ago Alright, the reproduce was shorter than I expected:
cargo new --bin crashtest
cd crashtest
echo "
[profile.release]
lto = true
" >> Cargo.tomlmake src/main.rs this:
#![feature(rustc_private)]
extern crate rustc_errors as errors;
fn main() { println!("Hello, world!"); }then
cargo build --release
=> crash
cargo 0.24.0-nightly (6529d418d 2017-11-29)
rustc 1.24.0-nightly (bb42071f6 2017-12-01)For convenience I made this a repo: https://github.com/matthiaskrgr/rustc_crashtest_lto (run cargo build --release on this)
matthiaskrgr
commented
6 years ago Still crashing with
rustc 1.25.0-nightly (6828cf901 2018-01-06)
cargo 0.25.0-nightly (a88fbace4 2017-12-29)Had a look at this again. Still crashing with
rustc 1.25.0-nightly (27a046e93 2018-02-18)
binary: rustc
commit-hash: 27a046e9338fb0455c33b13e8fe28da78212dedc
commit-date: 2018-02-18
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 6.0This is the code causing the assert
// Same thing as above, but for dynamic crates instead of static crates.
fn add_dynamic_crate(cmd: &mut Linker, sess: &Session, cratepath: &Path) {
// If we're performing LTO, then it should have been previously required
// that all upstream rust dependencies were available in an rlib format.
assert!(!is_full_lto_enabled(sess));
// Just need to tell the linker about where the library lives and
// what its name is
let parent = cratepath.parent();
if let Some(dir) = parent {
cmd.include_path(&fix_windows_verbatim_for_gcc(dir));
}
let filestem = cratepath.file_stem().unwrap().to_str().unwrap();
cmd.link_rust_dylib(&unlib(&sess.target, filestem),
parent.unwrap_or(Path::new("")));
}The problem might be that by trying to import parts of rustc it is required that we have these parts of rustc compiled as rlib and prepared for the lto which however might not be the case. Im still curious though why this is not a problem when using thinlto.
matthiaskrgr
commented
6 years ago rustc_private tracking issue: #27812
matthiaskrgr
commented
5 years ago rustc 1.33.0-nightly (9eac38634 2018-12-31)
The ICE is still happening but the backtrace and assert message slightly changed
Compiling crashtest v0.1.0 (/tmp/crashtest)
thread 'rustc' panicked at 'assertion failed: !are_upstream_rust_objects_already_included(sess)', src/librustc_codegen_llvm/back/link.rs:1402:9
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:70
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:58
at src/libstd/panicking.rs:200
3: std::panicking::default_hook
at src/libstd/panicking.rs:215
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:482
6: std::panicking::begin_panic
7: rustc_codegen_llvm::back::link::link_natively
8: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::join_codegen_and_link::{{closure}}
9: rustc::util::common::time
10: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::join_codegen_and_link
11: rustc_driver::driver::compile_input
12: rustc_driver::run_compiler_with_pool
13: <scoped_tls::ScopedKey<T>>::set
14: rustc_driver::run_compiler
15: <scoped_tls::ScopedKey<T>>::set
16: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
17: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:92
18: <F as alloc::boxed::FnBox<A>>::call_box
19: std::sys::unix::thread::Thread::new::thread_start
at /rustc/9eac386342c601b14311b435f2b6d314fc817bb5/src/liballoc/boxed.rs:734
at src/libstd/sys_common/thread.rs:14
at src/libstd/sys/unix/thread.rs:81
20: start_thread
21: clone
query stack during panic:
end of query stack
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.33.0-nightly (9eac38634 2018-12-31) running on x86_64-unknown-linux-gnu
note: compiler flags: -C opt-level=3 -C lto -C target-cpu=native --crate-type bin
note: some of the compiler flags provided by cargo are hidden
error: Could not compile `crashtest`.
To learn more, run the command again with --verbose.
Centril
commented
4 years ago @matthiaskrgr Does this still reproduce on a current nightly?
matthiaskrgr
commented
4 years ago The minimal example works. I was able to build clippy with lto=true. rls got linker errors with lto=true (do we want a ticket about that?) rustfmt builds miri gets linker errors as well
Centril
commented
4 years ago Ok, should we add a test perhaps?
matthiaskrgr
commented
4 years ago Yeah, definitely, I'll have a look. :)
EDIT: repo for reproducing: https://github.com/matthiaskrgr/rustc_crashtest_lto , run cargo build --release
crashes rustc: