[Regression] LLVM asserts "conflicting locations for variable" since 1.82 #131944
Comments
cuviper
added
C-bug
rustbot
added
I-prioritize
cuviper
added
the
A-LLVM
|
FWIW, I also shared some LLVM bitcode in this thread: |
jieyouxu
added
T-compiler
|
I can reproduce this. I haven't gotten to the bottom of it yet but I think it's an interaction between MIR inlining and an LLVM optimization (not clear to me yet whether it's SROA, inlining, or both). The final bitcode is obviously garbage. Seeing how the LLVM IR evolves through the passes would be helpful, if you can easily isolate that. |
|
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-critical |
rustbot
added
P-critical
|
From Then The only define void @_RINvXNvNtCs9ZNb7xDE5eg_18cargo_util_schemas8manifestsz_1__NtB5_14TomlLintConfigNtNtCsf9srf7wTiBp_5serde3ser9Serialize9serializeQNtNtNtCs6BCulG6QBAB_9toml_edit3ser3map18MapValueSerializerECsdFtfruI8BjD_5cargo(ptr %0, i64 %1) !dbg !4 {
%3 = alloca [0 x [0 x [24 x i8]]], i32 0, align 8
%4 = alloca [24 x i8], align 8
#dbg_declare(ptr %3, !11, !DIExpression(), !20)
#dbg_declare(ptr %4, !11, !DIExpression(), !20)
%.not = icmp eq i64 %1, 0, !dbg !23
br i1 %.not, label %5, label %common.reti.e. two !11 = !DILocalVariable(name: "self", arg: 1, scope: !12, file: !13, line: 1994, type: !18) |
|
is no-opt.bc the bitcode version of the IR rustc emits, before LLVM starts messing with it? |
Yes |
|
Ok, thanks. |
|
FWIW, I've got a CI change that hits this in #132010, so hopefully we'll catch this kind of thing sooner next time. |
|
The underlying issue here is a bad interaction between #128861 and proc macros. For reasons I don't understand (most likely details of LLVM's optimization pipeline) this sometimes but not always trips the reported assertion. But it's fairly easy to cause rustc to generate IR where the same DIVariable and the same DILocation have two different declarations: a proc macro that generates code that uses the same inlined function twice will do it. #128861 effectively relies on the callsite span to produce a different DILocation and thus disambiguate different dbg_declares, but proc macros appear to have a single span for the entire macro site. This comment |
|
I reduced a bit: // lib.rs
use serde::Serialize;
use toml_edit::ser::ValueSerializer;
#[derive(Serialize)]
pub struct TomlLintConfig2 {
pub priority: i8,
#[serde(flatten)]
pub config: toml::Table,
}
#[no_mangle]
pub fn ser(value: TomlLintConfig2, serializer: ValueSerializer) -> Result<toml_edit::Value, toml_edit::ser::Error> {
value.serialize(serializer)
}# Cargo.toml
[package]
name = "pr131944"
version = "0.1.0"
edition = "2021"
[dependencies]
toml = "=0.8.19"
toml_edit = { version = "=0.22.22", features = ["serde"] }
serde = { version = "=1.0.210", features = ["derive"] }
[profile.release]
lto = false
opt-level = 2
codegen-units = 3
debug = "full"I can reproduce it using stage1. |
|
I think the correct fix here is to assign discriminators to DILocations corresponding to call sites inside proc macro bodies. That's work I can do but it's going to take time and I think that's way too scary to ship directly to stable. If this is considered severe enough to spin a dot release (or to tag along with other stuff on a dot release) I think the thing to do is to back this out (it does revert cleanly from 1.82.0, though I didn't run tests) or to drop debug info that would conflict and trigger the assertion. I believe this patch would do the latter, though my testing so far is limited to building rustc itself, verifying that it fixes the reported regression, and checking that it doesn't regress the test from #128861. diff --git a/compiler/rustc_codegen_ssa/src/mir/debuginfo.rs b/compiler/rustc_codegen_ssa/src/mir/debuginfo.rs
index 146f55f95c2..7d739680be2 100644
--- a/compiler/rustc_codegen_ssa/src/mir/debuginfo.rs
+++ b/compiler/rustc_codegen_ssa/src/mir/debuginfo.rs
@@ -479,7 +479,7 @@ pub(crate) fn compute_per_local_var_debug_info(
let mut per_local = IndexVec::from_elem(vec![], &self.mir.local_decls);
let mut constants = vec![];
- let mut params_seen: FxHashMap<_, Bx::DIVariable> = Default::default();
+ let mut params_seen: FxHashMap<_, (Bx::DIVariable, Span, mir::SourceScope)> = Default::default();
for var in &self.mir.var_debug_info {
let dbg_scope_and_span = if full_debug_info {
self.adjusted_span_and_dbg_scope(var.source_info)
@@ -498,7 +498,7 @@ pub(crate) fn compute_per_local_var_debug_info(
}
};
- let dbg_var = dbg_scope_and_span.map(|(dbg_scope, _, span)| {
+ let dbg_var = dbg_scope_and_span.and_then(|(dbg_scope, _, span)| {
let var_kind = if let Some(arg_index) = var.argument_index
&& var.composite.is_none()
&& let mir::VarDebugInfoContents::Place(place) = var.value
@@ -524,18 +524,28 @@ pub(crate) fn compute_per_local_var_debug_info(
VariableKind::LocalVariable
};
- if let VariableKind::ArgumentVariable(arg_index) = var_kind {
+ Some(if let VariableKind::ArgumentVariable(arg_index) = var_kind {
match params_seen.entry((dbg_scope, arg_index)) {
- Entry::Occupied(o) => o.get().clone(),
+ Entry::Occupied(o) => {
+ let (seen_var, seen_span, seen_source_scope) = o.get();
+ if *seen_span == span && *seen_source_scope != var.source_info.scope {
+ return None;
+ } else {
+ seen_var.clone()
+ }
+ },
Entry::Vacant(v) => v
- .insert(
+ .insert((
self.cx.create_dbg_var(var.name, var_ty, dbg_scope, var_kind, span),
- )
+ span,
+ var.source_info.scope,
+ ))
+ .0
.clone(),
}
} else {
self.cx.create_dbg_var(var.name, var_ty, dbg_scope, var_kind, span)
- }
+ })
});
let fragment = if let Some(ref fragment) = var.composite {
|
|
I added your patch to #132010 to try it.
This is minor and off-topic, but if you make that a |
|
Yeah I'm used to writing stable Rust and not rustc Rust. |
|
@rustbot claim |
… into a single point. LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM. This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling. Fixes rust-lang#131944
Add discriminators to DILocations when multiple functions are inlined into a single point. LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM. This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling. Fixes rust-lang#131944
Add discriminators to DILocations when multiple functions are inlined into a single point. LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM. This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling. Fixes rust-lang#131944 try-job: x86_64-msvc try-job: i686-msvc
Add discriminators to DILocations when multiple functions are inlined into a single point. LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM. This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling. Fixes rust-lang#131944 try-job: x86_64-msvc try-job: i686-msvc try-job: x86_64-mingw try-job: aarch64-apple try-job: test-various try-job: dist-various-1 try-job: armhf-gnu
Add discriminators to DILocations when multiple functions are inlined into a single point. LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM. This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling. Fixes rust-lang#131944 try-job: x86_64-msvc try-job: i686-msvc try-job: x86_64-mingw try-job: aarch64-apple try-job: test-various try-job: dist-various-1 try-job: armhf-gnu
Add discriminators to DILocations when multiple functions are inlined into a single point. LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM. This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling. Fixes rust-lang#131944 try-job: x86_64-msvc try-job: i686-msvc try-job: x86_64-mingw try-job: aarch64-apple try-job: test-various try-job: dist-various-1 try-job: armhf-gnu
… into a single point. LLVM does not expect to ever see multiple dbg_declares for the same variable at the same location with different values. proc-macros make it possible for arbitrary code, including multiple calls that get inlined, to happen at any given location in the source code. Add discriminators when that happens so these locations are different to LLVM. This may interfere with the AddDiscriminators pass in LLVM, which is added by the unstable flag -Zdebug-info-for-profiling. Fixes rust-lang#131944
Drop debug info instead of panicking if we exceed LLVM's capability to represent it Recapping a bit of history here: In rust-lang#128861 I made debug info correctly represent parameters to inline functions by removing a fake lexical block that had been inserted to suppress LLVM assertions and by deduplicating those parameters. LLVM, however, expects to see a single parameter _with distinct locations_, particularly distinct inlinedAt values on the DILocations. This generally worked because no matter how deep the chain of inlines it takes two different call sites in the original function to result in the same function being present multiple times, and a function call requires a non-zero number of characters, but macros threw a wrench in that in rust-lang#131944. At the time I thought the issue there was limited to proc-macros, where an arbitrary amount of code can be generated at a single point in the source text. In rust-lang#132613 I added discriminators to DILocations that would otherwise be the same to repair rust-lang#131944[^1]. This works, but LLVM's capacity for discriminators is not infinite (LLVM actually only allocates 12 bits for this internally). At the time I thought it would be very rare for anyone to hit the limit, but rust-lang#132900 proved me wrong. In the relatively-minimized test case it also became clear to me that the issue affects regular macros too, because the call to the inlined function will (without collapse_debuginfo on the macro) be attributed to the (repeated, if the macro is used more than once) textual callsite in the macro definition. This PR fixes the panic by dropping debug info when we exceed LLVM's maximum discriminator value. There's also a preceding commit for a related but distinct issue: macros that use collapse_debuginfo should in fact have their inlinedAts collapsed to the macro callsite and thus not need discriminators at all (and not panic/warn accordingly when the discriminator limit is exhausted). Fixes rust-lang#132900 r? `@jieyouxu` [^1]: Editor's note: `fix` is a magic keyword in PR description that apparently will close the linked issue (it's closed already in this case, but still).
Code
I tried this code: cargo itself, building release + debug=2
(multiple versions, but at the time of this report I have cargo
cf53cc54bb593b5ec3dc2be4b1702f50c36d24d5)I expected to see this happen: successful compilation
Instead, this happened:
In Fedora 39 builds (with its LLVM 17),
rustchits alibstdc++assertion via LLVM:While investigating, I found that
llcalso crashes with the extracted IR:https://bugzilla.redhat.com/show_bug.cgi?id=2226564#c10
In local builds with rust's LLVM 19 and assertions enabled, and also with CI "alt" builds, LLVM asserts "conflicting locations for variable":
Version it worked on
It most recently worked on: Rust 1.81.0
Version with regression
Rust 1.82.0, but at first it only crashed in my Fedora 39 build with LLVM 17. However, using the bundled rust-llvm with assertions enabled does trigger a debuginfo assertion.
Current nightly (e92993d) in alt mode reproduces this as well.
i.e.
rustup-toolchain-install-master --alt e92993dbb43f0a5d17fe56e2d82f90435d6521c8Backtrace
(gdb) backtraceI bisected this to #128861 (cc @khuey)
3139ff09e9d07f7700f8d15ed25a231e29c43627-alt(3139ff0)026e9ed3f0c5b3ee6233fd23b5e497cb94cf6434-alt(its parent 026e9ed)@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged
The text was updated successfully, but these errors were encountered: