What causes "corrupt rlib" in rust-lang/rust?

Delete the offending rlib and rebuild: `cargo clean` (or remove the specific `*.rlib`) then `cargo build`.

corrupt rlib

Error message

corrupt rlib

What it means

Thrown by `child.data(&*archive_data).expect("corrupt rlib")` in lto.rs:112 while iterating the archive's rust object members during LTO. The archive parsed fine, but reading the raw bytes of an individual archive member failed — meaning the archive is structurally a valid `ar` container but one of its object members is truncated, has an invalid offset/size, or the backing data is shorter than the member header claims.

Source

Thrown at compiler/rustc_codegen_llvm/src/back/lto.rs:112

    for path in each_linked_rlib_for_lto {
        let archive_data = unsafe {
            Mmap::map(std::fs::File::open(&path).expect("couldn't open rlib"))
                .expect("couldn't map rlib")
        };
        let archive = ArchiveFile::parse(&*archive_data).expect("wanted an rlib");
        let metadata_link = rmeta_link::read(&archive, &archive_data, &path).unwrap();
        let obj_files = archive
            .members()
            .filter_map(|child| {
                child
                    .ok()
                    .and_then(|c| std::str::from_utf8(c.name()).ok().map(|name| (name.trim(), c)))
            })
            .filter(|&(name, _)| metadata_link.rust_object_files.iter().any(|f| f == name));
        for (name, child) in obj_files {
            info!("adding bitcode from {}", name);
            match get_bitcode_slice_from_object_data(
                child.data(&*archive_data).expect("corrupt rlib"),
                cgcx,
            ) {
                Ok(data) => {
                    let module = SerializedModule::FromRlib(data.to_vec());
                    upstream_modules.push((module, CString::new(name).unwrap()));
                }
                Err(e) => dcx.emit_fatal(e),
            }
        }
    }

    (symbols_below_threshold, upstream_modules)
}

fn get_bitcode_slice_from_object_data<'a>(
    obj: &'a [u8],
    cgcx: &CodegenContext,
) -> Result<&'a [u8], LtoBitcodeFromRlib> {

View on GitHub (pinned to 22057b88b0)

Solutions

Delete the offending rlib and rebuild: `cargo clean` (or remove the specific `*.rlib`) then `cargo build`.
Check free disk space and that no other process is writing to `target/` concurrently.
Re-run on local disk (avoid NFS/SMB that may truncate or cache-incoherently write large files).
Disable any antivirus/scan-on-close for the `target/` directory.
If reproducible across clean builds, file a rustc issue with the rlib and the `-C lto` invocation, since a structurally malformed member is a compiler bug.

Example fix

# before: archive header OK but member data truncated
lto.rs:112  panic: corrupt rlib

# after: ensure atomic, complete rlib writes
cargo clean
# avoid concurrent builds sharing one target dir
cargo build --release

Defensive patterns

Strategy: fallback

Validate before calling

fn archive_members_ok(data: &[u8]) -> bool {
    object::read::archive::ArchiveFile::parse(data)
        .map(|a| a.members().all(|m| m.is_ok()))
        .unwrap_or(false)
}

Try / catch

match std::panic::catch_unwind(|| invoke_lto()) {
    Ok(v) => v,
    Err(_) => { /* one archive member is corrupt -> cargo clean + full rebuild */ }
}

Prevention

Never SIGKILL a build mid-write; interrupted writes truncate rlib members.
Ensure the disk is not full or suffering hardware errors during codegen.
Run `cargo clean` after a crash or power loss before rebuilding.
Keep Cargo.lock stable so the same dependency tree is regenerated deterministically.

When it happens

Trigger: Triggered during LTO when `child.data()` returns `Err` for a member whose name matches `metadata_link.rust_object_files`: partial write truncated the archive tail, an object member size field is larger than the file, or the archive was assembled incorrectly by a buggy/old rustc. Only members identified as Rust object files reach this call.

Common situations: Interrupted/killed build left a `.rlib` with a complete header but truncated member data; disk filled mid-write; concurrent writers to the same rlib path; copying `target/` over a channel that truncated large files; using a hand-built toolchain whose archive writer mis-encodes member sizes; antivirus/quarantine modifying the rlib after write.

Related errors

AI-assisted analysis of rust-lang/rust@22057b88b0 (2026-08-03). Data as JSON: /data/errors/9a0edf041e94d629.json. Report an issue: GitHub.