-
Notifications
You must be signed in to change notification settings - Fork 13.3k
rust-analyser segfault with lto=thin, linker=lld-link #71504
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I managed to create a smaller reproducer: [package]
name = "rust-71504"
version = "0.1.0"
authors = ["Vincent Rouillé <vincent@speedy37.fr>"]
edition = "2018"
[dependencies]
globset = "0.4.5"
[profile.release]
lto = "thin" use globset::GlobSetBuilder;
fn main() {
assert!(GlobSetBuilder::new().build().unwrap().is_match("src/tests"));
}
|
Does this reproduce on nightly? |
Yes with rustc 1.44.0-nightly (b2e36e6 2020-04-22) And the generated code that crash is the same:
|
globset::pathutil::file_name llvm-ir
memchr::x86::memrchr::detect llvm-ir
Probable relevant part:
Assembly and llvm-ir files: deps.zip |
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good cc @AminArria @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @jakevossen5 @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke |
@rustbot ping llvm |
Hey LLVM ICE-breakers! This bug has been identified as a good cc @comex @CrazyDebugger @cuviper @DutchGhost @hanna-kruppe @hdhoang @heyrutvik @JOE1994 @jryans @mmilenko @nagisa @nikic @Noah-Kennedy @SiavoshZarrasvand @spastorino @vertexclique |
Assigning |
I've used the example code in #71504 (comment), but can't reproduce. Neither in stable nor in nightly for windows and macOS.
|
I'm sorry, I forgot to unset my global linker setting, I was using "lld-link". With the official link.exe, this bug doesn't occur. So this is an lld (LLVM 10) bug, the first I encounter. So I guess this is out of rust-lang scope. I there any target where lld is the official linker? Might be a COFF only bug tho. Changing the linker back to the default one, also fixed the compilation of rust-analyser, lto=fat, target-cpu=native btw (52s total vs 100s with the official build, I'm happy). |
cc @Gankra (relevant to the LLD-by-default plans) |
Removing |
Yes, embedded ARM targets use it by default. They're ELF targets though, and LLD's ELF backend is fairly reliable (I've only witnessed it corrupting debuginfo once, not cause crashes like this). |
Well I'have been using lld-link as default rust linker on windows for about 2 years now: no issue. PS: I was able to reproduce it with lld-link 9.0.1 and 10.0.0 |
After some discussion during triage meeting, we've decided to change the priority to |
I was able to repro this with the following steps:
[target.x86_64-pc-windows-msvc]
linker = "lld-link.exe"
I can confirm that this is |
This no longer occurs on the latest nightly. I bisected the fix to 63d0377 (in The relevant change seems to be rust-lang/cargo#8192. Were the 'unused' object files somehow affecting LTO? |
Minimized: fn main() {
memchr::memrchr(b'a', b"b");
} given |
Minimized even further: // lib.rs
use std::sync::atomic::{AtomicPtr, Ordering};
#[inline(always)]
pub fn memrchr() {
fn detect() {}
static FN: AtomicPtr<()> = AtomicPtr::new(detect as *mut ());
unsafe {
let fun = FN.load(Ordering::SeqCst);
std::mem::transmute::<*mut (), fn()>(fun)()
}
}
// main.rs
fn main() {
badlld::memrchr();
} These functions must be in two different crates, and be compiled with the setup described in #71504 (comment) |
Closing based on the comments by @Aaron1011 |
Should this be closed without a regression test being committed? |
Can we just toss your example in a compile-fail? |
I was having fun compiling rust-analyser for maximizing performance on my machine.
Compiling commit ec645f2 of rust-analyser with lto=fat seems to work as expected.
But this configuration on windows:
Result in rust-analyser segfaut:
Meta
Backtrace
Frame 0 Assembly
Frame 0 Registers
So this function seams to be miss compiled:
https://github.com/BurntSushi/ripgrep/blob/a2e6aec7a4d9382941932245e8854f0ae5703a5e/crates/globset/src/pathutil.rs#L9
In particular this line:
The text was updated successfully, but these errors were encountered: