Re: rustc from trixie-backports crashes compiling compiler-builtins

On Thu, Jan 29, 2026 at 11:30 AM Fabian Grünbichler
<[email protected]> wrote:
>
> > Am 28. Januar 2026 16:02:49 MEZ schrieb Matthew Gabeler-Lee <[email protected]>:
> >>I'm trying to build https://github.com/microsoft/edit using the bpo
> >>version of cargo & rustc, and running into a compiler crash:
> >>
> >>Repro:
> >>1. Install rustc, rust-src, and cargo from trixie-backports
> >>(1.90.0+dfsg1-1~bpo13+2)
> >>2. Clone https://github.com/microsoft/edit
> >>3. Build with: RUSTC_BOOTSTRAP=1 cargo build --config
> >>.cargo/release.toml --release
> >>4. rustc crashes with SIGSEGV
> >>
> >>The top of the backtrace is:
> >>error: rustc interrupted by SIGSEGV, printing backtrace
> >>
> >>/lib/x86_64-linux-gnu/librustc_driver-1986f22fdc122ac9.so(+0x960ba5)
> >>[0x7fe9f0960ba5]
> >>/lib/x86_64-linux-gnu/libc.so.6(+0x3fdf0) [0x7fe9efe4adf0]
> >>/lib/x86_64-linux-gnu/libLLVM.so.19.1(+0x23b294a) [0x7fe9ea3b294a]
> >>/lib/x86_64-linux-gnu/libLLVM.so.19.1(_ZN4llvm16ConstantFoldCallEPKNS_8CallBaseEPNS_8FunctionENS_8ArrayRefIPNS_8ConstantEEEPKNS_17TargetLibraryInfoEb+0x13c)
> >>[0x7fe9ea3af6ec]
> >>
> >>The full crash output is here:
> >>https://gist.github.com/fastcat/b41a69b0c171e9a8dacec9b6b5a48837
> >>
> >>If I use the rust:1.90.0-trixie docker image to do the build, it
> >>doesn't crash. Similarly if I use rustc 1.90.1 from a forky docker
> >>container, it also doesn't crash. This seems to point to it being
> >>something haywire with the BPO build, or perhaps with its
> >>dependencies?
>
> I don't know what those docker images contain, so can't tell. If they contain
> upstream toolchains, those use a different LLVM build and different Rust
> toolchain settings, which might explain the different behaviour/results.

Digging in, the upstream rust docker image is using LLVM 20:

root@3b6fbae897a4:/usr/local/rustup/toolchains/1.90.0-x86_64-unknown-linux-gnu/bin#
ldd ./rustc | grep -i llvm
    libLLVM.so.20.1-rust-1.90.0-stable =>
/usr/local/rustup/toolchains/1.90.0-x86_64-unknown-linux-gnu/bin/./../lib/../lib/libLLVM.so.20.1-rust-1.90.0-stable
(0x00007f7483800000)


> In general RUSTC_BOOTSTRAP is not for public consumption, it is an
> escape hatch for building the compiler itself (which uses unstable
> features, but needs to be buildable with the stable toolchain).
>
> Similarly, `-Zbuild-std` is not stabilized yet, and a quite big feature at
> that.

I too am frustrated by this. This project seems to continually use
unstable features that require the bootstrap flag or a nightly build
of rust. Every time the features they use stabilize, they find new
unstable/nightly features to depend on :(

> I will upload 1.91.1 to trixie-backports as soon as the LLVM situation is
> sorted out. It will upgrade LLVM to 21 (compared to 19 as used by 1.90). If the
> issue is caused by LLVM, this might explain the results (upstream "supports" a
> range of LLVM versions for each rustc version, but only fully tests things with
> the upstream default combination).

Fingers crossed!

> Both rustc and llvm come with -dbgsym packages (but they are in a separate part
> of the archive)

Thanks!

> If you manage to find out more, I'd be happy to take another look. I won't
> proactively try to find out more myself, since `edit` is requiring/recommending
> things which are outside of the scope of what the stable toolchain is expected
> to support, and the next version will likely fix the issue at hand anyway.

Fair.

I had to install systemd-coredump to get a dump captured for whatever
reason, but once I had that, and the dbgsym packages, and debuginfod
enabled, I was able to get a symbolized backtrace from the crash. The
top of the backtrace is:

#0  getLibFunc () at llvm/include/llvm/Analysis/TargetLibraryInfo.h:347
#1  ConstantFoldScalarCall1 () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/ConstantFolding.cpp:2127
#2  ConstantFoldScalarCall () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/ConstantFolding.cpp:3239
#3  0x00007f4bb8faf6ec in ConstantFoldCall () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/ConstantFolding.cpp:3502
#4  0x00007f4bb901e213 in simplifyCallSite () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/InlineCost.cpp:2253
#5  visitCallBase () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/InlineCost.cpp:2293
#6  0x00007f4bb90199e1 in visit () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/InlineCost.cpp:2566
#7  visit () at llvm/include/llvm/IR/InstVisitor.h:111
#8  analyzeBlock () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/InlineCost.cpp:2566
#9  0x00007f4bb90157ab in analyze () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/InlineCost.cpp:2794
#10 0x00007f4bb9014a2f in getInlineCost () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/InlineCost.cpp:3074
#11 0x00007f4bb90148df in getInlineCost () at
build-llvm/tools/clang/stage2-bins/llvm/lib/Analysis/InlineCost.cpp:2938

Again, the full output is quite large, so I've put it here
https://gist.github.com/fastcat/780acacc4b369a8c38bc441c333d5c8d