Skip to content
Latchkey

Rust Linker OOM with High codegen-units in CI

Many codegen units plus full debug info produce large object files, and the final link loads them together - spiking memory at the link step. On a small runner that spike triggers an OOM kill.

What this error means

The build compiles all crates, then the linker (ld/lld) is killed or the job dies with exit 137 specifically during linking - not in any one rustc invocation. Lowering debug info or codegen units makes it pass.

cargo output
  = note: collect2: fatal error: ld terminated with signal 9 [Killed]
          compilation terminated.

error: linking with `cc` failed: signal: 9 (SIGKILL)

Common causes

Large object files at link time

High codegen-units plus full debug = 2 info produce many large objects; the linker maps them all into memory at once, peaking well above per-crate compile memory.

Debug symbols inflating the link

Full debuginfo in a workspace with many crates balloons the linker’s working set, which is what gets OOM-killed.

How to fix it

Lower codegen-units and debug info

Fewer, larger codegen units and reduced debuginfo cut the linker’s peak memory.

Cargo.toml
[profile.dev]
codegen-units = 16
debug = 1            # line tables only, much smaller

[profile.release]
codegen-units = 1
lto = "thin"

Split or strip debug info

Splitting debuginfo into separate files keeps it out of the link’s peak working set.

.cargo/config.toml
# .cargo/config.toml
[profile.dev]
split-debuginfo = "unpacked"

How to prevent it

  • Tune codegen-units, debug, and lto for CI’s memory budget.
  • Use split-debuginfo so debug data doesn’t inflate the link.
  • Right-size the runner for the linker’s peak, not the average.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →