rust-lang/rust · critical

couldn't map rlib

Error message

couldn't map rlib

What it means

Thrown by `.expect("couldn't map rlib")` on `Mmap::map(file)` in lto.rs:97 during LTO upstream rlib loading. The rlib file opened successfully but memory-mapping it failed, aborting the compiler. `Mmap::map` fails on I/O errors, empty files, files on filesystems that forbid mmap (e.g. some FUSE/network mounts), or when virtual address space is exhausted.

Source

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

    // __llvm_profile_counter_bias is pulled in at link time by an undefined reference to
    // __llvm_profile_runtime, therefore we won't know until link time if this symbol
    // should have default visibility.
    symbols_below_threshold.push(c"__llvm_profile_counter_bias".to_owned());

    // LTO seems to discard this otherwise under certain circumstances.
    symbols_below_threshold.push(c"rust_eh_personality".to_owned());

    // If we're performing LTO for the entire crate graph, then for each of our
    // upstream dependencies, find the corresponding rlib and load the bitcode
    // from the archive.
    //
    // We save off all the bytecode and LLVM module ids for later processing
    // with either fat or thin LTO
    let mut upstream_modules = Vec::new();
    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) => {

View on GitHub (pinned to 22057b88b0)

Solutions

  1. Delete the truncated rlib and rebuild: `cargo clean` (or remove the specific `target/release/deps/*.rlib`) then rebuild.
  2. Move the project off network/FUSE mounts onto a local filesystem that supports mmap.
  3. Free disk space and rebuild (a full disk can leave zero-byte artifacts).
  4. If on a 32-bit target/host, switch to a 64-bit toolchain to avoid address-space exhaustion during mmap.
  5. Verify the rlib size is non-zero (`ls -l`) and check `dmesg`/audit logs for mmap denials (SELinux/AppArmor).

Example fix

# before: mmap fails on a truncated/zero-byte rlib
cargo build --release  # panic: couldn't map rlib

# after: ensure non-corrupt artifacts on a mmap-capable filesystem
cargo clean
ls -l target/release/deps/   # confirm rlibs are non-zero after rebuild
cargo build --release
Defensive patterns

Strategy: retry

Validate before calling

fn ensure_mappable(path: &std::path::Path) -> std::io::Result<()> {
    let len = std::fs::metadata(path)?.len();
    if len == 0 {
        return Err(std::io::Error::new(std::io::ErrorKind::InvalidData, "empty rlib"));
    }
    Ok(())
}

Try / catch

for attempt in 0..3 {
    match std::panic::catch_unwind(|| invoke_lto()) {
        Ok(v) => break v,
        Err(_) if attempt < 2 => { std::thread::sleep(std::time::Duration::from_millis(200 * (attempt+1) as u64)); continue; }
        Err(_) => { /* report mmap exhaustion / resource issue */ }
    }
}

Prevention

When it happens

Trigger: Triggered when `-C lto` is enabled and the compiler successfully `open()`s an upstream rlib but `Mmap::map` returns `Err`: the rlib is 0 bytes (truncated), lives on a filesystem without mmap support, exceeds address-space limits on 32-bit hosts, or the OS denies the mapping for I/O reasons.

Common situations: Empty/truncated rlib from a prior interrupted `cargo build` (e.g. killed during codegen); building on a tmpfs/FUSE/SMB mount that rejects mmap; running a 32-bit toolchain against very large dependency graphs; disk-full / write-corrupted artifacts in `target/`; SELinux/AppArmor denying mmap of build artifacts.

Related errors

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