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.

Frequently asked questions

What causes "codegen-units memory blowup"?
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.
How do I fix codegen-units memory blowup?
Fewer, larger codegen units and reduced debuginfo cut the linker’s peak memory.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card