ICE: worker thread panicked: cached cgu should have an object file but doesn't

[GymVodTruth]

Code

use std::sync::Mutex;

use colorsys::Rgb;
use image::GenericImageView;

static GLOBAL_VEC: once_cell::sync::Lazy<Mutex<Vec<String>>> =
    once_cell::sync::Lazy::new(|| Mutex::new(Vec::new()));

pub fn compile_image(filename: String) {
    let img = image::open(filename).expect("Couldn't read Image file");

    for pixel in img.pixels() {
        let rgba_color = Rgb::from((
            pixel.2 .0[0] as f32,
            pixel.2 .0[1] as f32,
            pixel.2 .0[2] as f32,
        ));

        let hex_color = rgba_color.to_hex_string();

        GLOBAL_VEC
            .lock()
            .expect("Failed to lock GLOBAL_VEC")
            .push(hex_color.replace("#", ""));
    }

    println!(
        "{:?}",
        GLOBAL_VEC
            .lock()
            .expect("Failed to lock GLOBAL_VEC")
            .join("")
            .to_string()
    )
}

Meta

rustc --version --verbose:

rustc 1.81.0 (eeb90cda1 2024-09-04)
binary: rustc
commit-hash: eeb90cda1969383f56a2637cbd3037bdf598841c
commit-date: 2024-09-04
host: x86_64-pc-windows-msvc
release: 1.81.0
LLVM version: 18.1.7

Error output

thread 'coordinator' panicked at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\compiler\rustc_codegen_ssa\src\back\write.rs:1676:29:
/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\compiler\rustc_codegen_ssa\src\back\write.rs:1676:29: worker thread panicked

error: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.81.0 (eeb90cda1 2024-09-04) running on x86_64-pc-windows-msvc

note: compiler flags: --crate-type bin -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED]

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: cached cgu 7stuw3ichib0b7t6li5vvuql5 should have an object file, but doesn't

Backtrace

stack backtrace:
   0:     0x7ffb6657408d - std::backtrace_rs::backtrace::dbghelp64::trace
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\..\..\backtrace\src\backtrace\dbghelp64.rs:91
   1:     0x7ffb6657408d - std::backtrace_rs::backtrace::trace_unsynchronized
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2:     0x7ffb6657408d - std::sys::backtrace::_print_fmt
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\sys\backtrace.rs:65
   3:     0x7ffb6657408d - std::sys::backtrace::impl$0::print::impl$0::fmt
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\sys\backtrace.rs:40
   4:     0x7ffb665a4bb9 - core::fmt::rt::Argument::fmt
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\core\src\fmt\rt.rs:173
   5:     0x7ffb665a4bb9 - core::fmt::write
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\core\src\fmt\mod.rs:1182
   6:     0x7ffb6656ab71 - std::io::Write::write_fmt<std::sys::pal::windows::stdio::Stderr>
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\io\mod.rs:1827
   7:     0x7ffb66577127 - std::panicking::default_hook::closure$1
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\panicking.rs:269
   8:     0x7ffb66576d19 - std::panicking::default_hook
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\panicking.rs:296
   9:     0x7ffb14732ed5 - memchr
  10:     0x7ffb6657796b - alloc::boxed::impl$50::call
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\alloc\src\boxed.rs:2084
  11:     0x7ffb6657796b - std::panicking::rust_panic_with_hook
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\panicking.rs:808
  12:     0x7ffb15baa6ff - object[443503632d93082a]::elf::gnu_hash
  13:     0x7ffb15ba29f9 - object[443503632d93082a]::elf::gnu_hash
  14:     0x7ffb15b917f3 - object[443503632d93082a]::elf::gnu_hash
  15:     0x7ffb15c3e66d - rustc_middle[1ecd3c849d31efbc]::util::bug::bug_fmt
  16:     0x7ffb15c1ea6d - rustc_middle[1ecd3c849d31efbc]::ty::consts::const_param_default
  17:     0x7ffb15c1e8ad - rustc_middle[1ecd3c849d31efbc]::ty::consts::const_param_default
  18:     0x7ffb15c3e5a2 - rustc_middle[1ecd3c849d31efbc]::util::bug::bug_fmt
  19:     0x7ffb1333f858 - rustc_interface[ce19ee65e5c643b1]::proc_macro_decls::proc_macro_decls_static
  20:     0x7ffb105c0ddd - llvm::DenseMap<llvm::StructType * __ptr64,llvm::detail::DenseSetEmpty,llvm::IRMover::StructTypeKeyInfo,llvm::detail::DenseSetPair<llvm::StructType * __ptr64> >::~DenseMap<llvm::StructType * __ptr64,llvm::detail::DenseSetEmpty,llvm::IRMover::StructTypeKeyIn
  21:     0x7ffb105d4c4f - llvm::DenseMap<llvm::StructType * __ptr64,llvm::detail::DenseSetEmpty,llvm::IRMover::StructTypeKeyInfo,llvm::detail::DenseSetPair<llvm::StructType * __ptr64> >::~DenseMap<llvm::StructType * __ptr64,llvm::detail::DenseSetEmpty,llvm::IRMover::StructTypeKeyIn
  22:     0x7ffb66588f0d - alloc::boxed::impl$48::call_once
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\alloc\src\boxed.rs:2070
  23:     0x7ffb66588f0d - alloc::boxed::impl$48::call_once
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\alloc\src\boxed.rs:2070
  24:     0x7ffb66588f0d - std::sys::pal::windows::thread::impl$0::new::thread_start
                               at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\sys\pal\windows\thread.rs:58
  25:     0x7ffc0be9e8d7 - BaseThreadInitThunk
  26:     0x7ffc0d17fbcc - RtlUserThreadStart

[lqd]

Why close the issue?

[saethlin]

This is another example of the problem I was trying to address in #120865. The highly custom threadpool that this part of the compiler uses turns fatal errors into ICEs. That's just one of the bugs here, the other bug is that an object file is missing and we don't recover gracefully from that scenario. We probably should.