*.rcgu.o files accumulate forever with -Csplit-debuginfo=unpacked since 1.88

[dasboe]

On macOS, every codegen invocation since 1.88 leaves a full set of *.rcgu.o files behind in target/debug/deps, and nothing ever cleans them up. Before 1.88 a rebuild overwrote the previous set.

I ran into this because the deps dir of our workspace had grown to 3.29 million files (341 GB) over roughly eight weeks of heavy use. At that size every rustc and rustdoc start spends minutes before doing anything useful, since the -L dependency directory is read eagerly at startup into a sorted index (#132910). cargo test --doc sat at 0% CPU for over half an hour; a sample of the process showed it inside getdirentries64 under SearchPath::new.

What I believe is going on: cargo defaults split-debuginfo to unpacked on macOS, so rustc deliberately keeps the object files after linking because the DWARF lives in them (preserve_objects_for_their_debuginfo). That was harmless while the object names were stable per unit, a rebuild simply replaced the old set. Then #139453 (shipped in 1.88) started prepending a per-invocation random string to temp file names so concurrent invocations can't collide. The preserved objects get that random component too, so now each rebuild writes a brand new set and the old ones just stay there forever.

Repro with any small lib crate (mine has 3 modules, so 3 CGUs):

$ for i in 1 2 3; do echo "// edit $i" >> src/lib.rs; cargo +1.85 build; done
$ ls target/debug/deps/*.rcgu.o | wc -l
3
$ rm -rf target && for i in 4 5 6; do echo "// edit $i" >> src/lib.rs; cargo +stable build; done
$ ls target/debug/deps/*.rcgu.o | wc -l
9

On 1.85.1 the files are named leakprobe-<metadata>.<cgu>.rcgu.o. On 1.95.0 there's an extra segment: leakprobe-<metadata>.<cgu>.<invocation-random>.rcgu.o. 1.88 and 1.97 behave like 1.95.

The dev profile defaults to 256 codegen units, so a large crate can leak a few hundred files per rebuild. A workspace that gets built and tested all day reaches millions of files in weeks, and the readdir cost of the bloated deps dir then taxes every compiler start in that workspace.

Deleting the stale objects doesn't upset cargo at all (everything still reports Fresh afterwards, you only lose debugger/backtrace symbolication for binaries that were already built), which suggests the backend could remove old *.rcgu.o matching the unit's extra-filename hash before writing the new set. rust-lang/cargo#16665 looks like the same problem seen from the outside (deps dir size blowing up incremental build times on macOS) without the cause identified.

Meta:

rustc 1.85.1 (4eb161250 2025-03-15)   does not leak
rustc 1.88.0 (6b00bc388 2025-06-23)   leaks
rustc 1.95.0 (59807616e 2026-04-14)   leaks
host: aarch64-apple-darwin, macOS 26.4

[dasboe]

Some concrete rate data from a second machine (same workspace, ~10 crates): a single full test-suite pass (fmt, clippy in two feature flavours, nextest in two flavours, doctests) leaks 6,838 new *.rcgu.o files into target/debug/deps. Starting from a clean tree that reaches 250k stale objects after about 34 suite runs, at which point directory enumeration cost is already noticeable on every compiler start.

[dasboe]

Workaround for anyone hitting this: the stale objects can simply be deleted, cargo does not fingerprint them and everything still reports Fresh afterwards. We run this periodically:

find target -name '*.rcgu.o' -mtime +2 -delete

The 2-day window keeps debugger/backtrace symbolication for recently built binaries. The only thing you lose for older binaries is symbolication, not correctness. Since the enumeration cost is what actually hurts, it pays to run this before deps gets large, a cheap trigger is checking the directory's inode size (on APFS it grows by 32 bytes per entry, so stat -f %z target/debug/deps divided by 32 approximates the entry count without paying the readdir).

[bjorn3]

I would expect this to happen with -Csplit-debuginfo=unpacked on all targets that support it, not just on macOS. The only reason nobody noticed this outside macOS is because Cargo only defaults to unpacked split debuginfo on macOS.

[dasboe]

Can confirm, just tried this on aarch64-unknown-linux-gnu (rustc 1.98.0, rust:latest docker image). Same leak with unpacked, except on ELF it's the *.rcgu.dwo files that pile up instead of *.rcgu.o:

cargo new t && cd t
export CARGO_PROFILE_DEV_SPLIT_DEBUGINFO=unpacked
for i in 1 2 3 4; do touch src/main.rs; cargo build -q; ls target/debug/deps | grep -c '\.rcgu\.dwo$'; done

prints 6, 12, 18, 24. Every rebuild drops a full new set under a fresh invocation suffix and the old ones just stay. Without the override nothing is left behind.

[JSorngard]

It seems like this can cause issues with certain network requests on macOS as the certificate validation process will by default walk the directory of the binary to find the "Info.plist" file. This can make tests take a long time: https://www.reddit.com/r/rust/s/oIpKn9UZ5T