LLVM "conflicting locations for variable" assertions

@yuri-sevatz

The "conflicting locations for variable" bug might still be around in rust-1.84 and rust-1.85. A bunch of us on Gentoo are consistently hitting this same SIGABORT when compiling firefox with newer rust installs. It's always seemingly when running the exact same build step too, so it appears to be 100% reproducible.

I managed to get a stacktrace here, not sure if this might explain what we're seeing more:

https://bugs.gentoo.org/949280#c13

Rust is a bit outside of my realm of expertise, but if you'd like us to try running anything else on the workdir right after it fails, we'll try and offer any evidence that we can.

Originally posted by @yuri-sevatz in #131944

Taking from the gentoo bug link for =www-client/firefox-136.0 =dev-lang/rust-1.85.0:

Core was generated by `/usr/lib/rust/1.85.0/bin/rustc --crate-name mls_platform_api --edition=2021 /va'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f47650a579c in ?? () from /usr/lib64/libc.so.6
[Current thread is 1 (Thread 0x7f47433e16c0 (LWP 20627))]
(gdb) where
#0  0x00007f47650a579c in ?? () from /usr/lib64/libc.so.6
#1  0x00007f47650504f6 in raise () from /usr/lib64/libc.so.6
#2  0x00007f47650388fa in abort () from /usr/lib64/libc.so.6
#3  0x00007f476503881e in ?? () from /usr/lib64/libc.so.6
#4  0x00007f4765048af6 in __assert_fail () from /usr/lib64/libc.so.6
#5  0x00007f4769b19e14 in llvm::Loc::MMI::addFrameIndexExpr(llvm::DIExpression const*, int) [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#6  0x00007f4769b26572 in llvm::DwarfDebug::collectVariableInfoFromMFTable(llvm::DwarfCompileUnit&, llvm::DenseSet<std::pair<llvm::DINode const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::pair<llvm::DINode const*, llvm::DILocation const*>, void> >&) [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#7  0x00007f4769b289c1 in llvm::DwarfDebug::collectEntityInfo(llvm::DwarfCompileUnit&, llvm::DISubprogram const*, llvm::DenseSet<std::pair<llvm::DINode const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::pair<llvm::DINode const*, llvm::DILocation const*>, void> >&) [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#8  0x00007f4769b2fac1 in llvm::DwarfDebug::endFunctionImpl(llvm::MachineFunction const*) [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#9  0x00007f4769aff39d in llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#10 0x00007f4769af77b8 in llvm::AsmPrinter::emitFunctionBody() [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#11 0x00007f47699021ef in llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#12 0x00007f4769e94539 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) [clone .part.0] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#13 0x00007f476b612ff7 in llvm::FPPassManager::runOnFunction(llvm::Function&) [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#14 0x00007f476b61323b in llvm::FPPassManager::runOnModule(llvm::Module&) [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#15 0x00007f476b613e6c in llvm::legacy::PassManagerImpl::run(llvm::Module&) [clone .localalias] () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#16 0x00007f47698ccde8 in LLVMRustWriteOutputFile () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#17 0x00007f476686c038 in rustc_codegen_llvm::back::write::write_output_file () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#18 0x00007f4766870e1c in rustc_codegen_llvm::back::write::codegen () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#19 0x00007f47668613e1 in rustc_codegen_ssa::back::write::finish_intra_module_work::<rustc_codegen_llvm::LlvmCodegenBackend> () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#20 0x00007f4766861769 in rustc_codegen_ssa::back::write::execute_optimize_work_item::<rustc_codegen_llvm::LlvmCodegenBackend> () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#21 0x00007f4766898e28 in std::sys::backtrace::__rust_begin_short_backtrace::<<rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa::back::write::spawn_work<rustc_codegen_llvm::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()> () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#22 0x00007f476689f2ff in <<std::thread::Builder>::spawn_unchecked_<<rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa::back::write::spawn_work<rustc_codegen_llvm::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()>::{closure#1} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} ()
   from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#23 0x00007f47697e7b6b in std::sys::pal::unix::thread::Thread::new::thread_start () from /usr/lib/rust/1.85.0/bin/../lib/librustc_driver-3d045d00de979894.so
#24 0x00007f47650a3a61 in ?? () from /usr/lib64/libc.so.6
#25 0x00007f4765124b6c in ?? () from /usr/lib64/libc.so.6

Potential reproducer according to the gentoo bug report is mls-platform-api v0.1.0 https://github.com/beurdouche/mls-platform-api?rev=19c3f18b747d13354370ba84440bb0b963932634#19c3f18b

/tmp/portage/dev-lang/rust-1.81.0-r100/work/rustc-1.81.0-src/src/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:298: void llvm::Loc::MMI::addFrameIndexExpr(const llvm::DIExpression*, int): Assertion `(FrameIndexExprs.size() == 1 || llvm::all_of(FrameIndexExprs, [](const FrameIndexExpr &FIE) { return FIE.Expr && FIE.Expr->isFragment(); })) && "conflicting locations for variable"' failed.

Are there STR that don't involve installing Gentoo?

I built 79b43df with LLVM assertions enabled, then used the stage 2 compiler to build mozilla/gecko-dev@e31c7b6 with --enable-debug --enable optimize, and I didn't hit any assertions.

@yuri-sevatz

cc @yuri-sevatz

Following steps from here:

#131944 (comment)

I manually re-ran the failing rustc invocation that portage had SIGABORT on earlier, only this time I added the one extra -C save-temps argument described in the link above:

CARGO=/usr/lib/rust/1.85.0/bin/cargo CARGO_CRATE_NAME=mls_platform_api CARGO_MANIFEST_DIR=/var/tmp/portage/www-client/firefox-136.0/work/firefox-136.0/third_party/rust/mls-platform-api CARGO_MANIFEST_PATH=/var/tmp/portage/www-client/firefox-136.0/work/firefox-136.0/third_party/rust/mls-platform-api/Cargo.toml CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='Apache-2.0 OR MIT' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=mls-platform-api CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.1.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/release/deps /usr/lib/rust/1.85.0/bin/rustc --crate-name mls_platform_api --edition=2021 /var/tmp/portage/www-client/firefox-136.0/work/firefox-136.0/third_party/rust/mls-platform-api/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C save-temps -C embed-bitcode=no --cfg 'feature="gecko"' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values("gecko"))' -C metadata=4834399fd08dda83 -C extra-filename=-6f0e17e1c38205ac --out-dir /var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C linker=/var/tmp/portage/www-client/firefox-136.0/work/firefox-136.0/build/cargo-linker -C strip=debuginfo -L dependency=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps -L dependency=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/release/deps --extern bincode=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libbincode-6eda4ca2d830b1d1.rmeta --extern hex=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libhex-13b92ff18ea896c7.rmeta --extern mls_rs=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libmls_rs-cf74ccb8d138ff9d.rmeta --extern mls_rs_crypto_nss=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libmls_rs_crypto_nss-4b7a5ea8c46af931.rmeta --extern mls_rs_provider_sqlite=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libmls_rs_provider_sqlite-e9356489aee85b1a.rmeta --extern serde=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libserde-c54d95cf87f62589.rmeta --extern serde_json=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libserde_json-e67cf20ea532da10.rmeta --extern sha2=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libsha2-62d86fcf55b99cb6.rmeta --extern thiserror=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libthiserror-aea814271850f1a8.rmeta --cap-lints warn -C debuginfo=2 --cap-lints warn -C codegen-units=1 -L native=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/dist/bin -L native=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/security/nss/lib/nss/nss_nss3 -L native=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/security/nss/lib/ssl/ssl_ssl3 -L native=/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/config/external/nspr/pr

It generated this:

find /var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps -newermt "$(date -d '10 minutes ago')" -type f -print
/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/mls_platform_api-6f0e17e1c38205ac.mls_platform_api.1bb01671ac1d6994-cgu.0.rcgu.o
/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/mls_platform_api-6f0e17e1c38205ac.mls_platform_api.1bb01671ac1d6994-cgu.0.rcgu.no-opt.bc
/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/libmls_platform_api-6f0e17e1c38205ac.rmeta
/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/mls_platform_api-6f0e17e1c38205ac.d
/var/tmp/portage/www-client/firefox-136.0/work/firefox_build/instrumented/x86_64-unknown-linux-gnu/release/deps/mls_platform_api-6f0e17e1c38205ac.mls_platform_api.1bb01671ac1d6994-cgu.0.rcgu.bc

... these files are attached in upload.zip below:

upload.zip

Here are the package versions which I had combined to get this, though others are saying it's the same result with dev-lang/rust-1.84* :

dev-lang/rust-1.85.0-r1
dev-lang/rust-common-1.85.0
www-client/firefox-1.36.0

On this particular Gentoo installation, every package (including rust itself) would have been built with the below globals set in /etc/portage/make.conf. CFLAGS/CXXFLAGS tend to affect everything that any compiler understands. CPU_FLAGS_X86 will affect only packages that include manually written steps to translate them to "build-system-specific" arguments.

CFLAGS="-march=haswell -mabm -maes --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=8192 -O2 -pipe -ggdb"
CXXFLAGS="-march=haswell -mabm -maes --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=8192 -O2 -pipe -ggdb"
CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3"

Since I've reproduced this on several other CPUs with a range of older as well as newer instruction sets, I don't think the above globals /etc/portage/make.conf matter that much.

Hope that helps... I'll try and see if it's easy to hit this with Gentoo's livecd. Their "GUI" livecd might be a little closer to being able to test this with a lot less steps, provided you have the RAM for it.

awslabs/mls-rs#231 looks potentially relevant

Yeah reverting that and then doing CARGO_PROFILE_RELEASE_DEBUG=2 RUSTC=<rustc with LLVM assertions enabled> cargo build --release --examples triggers the assertion.

I have confirmed that applying the same workaround to the 'mls-platform-api' folder in firefox's source code avoids the crash in rustc when compiling Gentoo's version of www-client/firefox-136.0.

Unfortunately the assertion goes away with -Ccodegen-units=1, which also means it goes away with --emit=llvm-ir.

Notably this asserts on 026e9ed i.e. the commit before #128861.

@rustbot

Disabling LTO also makes this go away.

@rustbot label A-LTO

@rustbot

Alright, after further investigation I think the LTO is just required to get SROA aggressive enough to trigger the assertion but isn't actually the root cause.

@rustbot label -A-LTO

The hacky commit that obscures this problem replaces the destructuring assignment

(a, b) = (b, c);

with a mem::replace call

a = mem::replace(&mut b, c);

That destructuring assignment is critical to tripping the assertion. Rustc desugars that assignment to

    { let (lhs, lhs) = (b, c); a = lhs; b = lhs; };

Note the repeated lhs. By the time we get to MIR these get broken into separate stack slots like so

            scope 3 {
                let _3: i32;
                let _4: i32;
                scope 4 {
                    debug lhs => _3;
                    debug lhs => _4;
                }
            }

and codegen proceeds the way one would expect. But that double lhs comes back to haunt us during debuginfo generation.

  %9 = alloca [24 x i8], align 8
  %10 = alloca [24 x i8], align 8
...
    #dbg_declare(ptr %10, !118437, !DIExpression(), !118494)
    #dbg_declare(ptr %9, !118437, !DIExpression(), !118495)
...
!118437 = !DILocalVariable(name: "lhs", scope: !118438, file: !4703, line: 138, type: !1291, align: 64)
!118438 = distinct !DILexicalBlock(scope: !118432, file: !4703, line: 138, column: 13)
...
!118494 = !DILocation(line: 138, column: 34, scope: !118438, inlinedAt: !118439) ; i.e. the rhs of the destructuring
!118495 = !DILocation(line: 138, column: 14, scope: !118438, inlinedAt: !118439) ; i.e. the lhs of the destructuring

rustc assigns both stack slots to the same DILocalVariable. Then, when the type is a struct (Vec in the repo in question) and SROA is aggressive enough to shred one of them into its constituents, the assertion is triggered.

That's a lot to unpack, but my first question is why are we generating debuginfo for compiler-introduced-vars at all?

Don't produce debug information for compiler-introduced-vars when des…

@rustbot

@rustbot claim

Rollup merge of rust-lang#138818 - khuey:138198, r=jieyouxu

Unrolled build for rust-lang#138818

Navigation Menu

Repository navigation

LLVM "conflicting locations for variable" assertions #138198

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

LLVM "conflicting locations for variable" assertions #138198

Description

Activity

jieyouxu commented on Mar 8, 2025

jieyouxu commented on Mar 8, 2025

khuey commented on Mar 8, 2025

jieyouxu commented on Mar 9, 2025

yuri-sevatz commented on Mar 9, 2025

khuey commented on Mar 9, 2025

khuey commented on Mar 9, 2025

yuri-sevatz commented on Mar 9, 2025

khuey commented on Mar 9, 2025

khuey commented on Mar 9, 2025

khuey commented on Mar 11, 2025

khuey commented on Mar 11, 2025

khuey commented on Mar 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions