Repository navigation
Relock OOM-killed in lockfile verification on 12.14.0, passes on 11.28.4 #17020
Description
Last pnpm version that worked
11.28.4
pnpm version
12.14.0
Code to reproduce the issue
Repro: https://github.com/jd-solanki/reproductions/tree/pnpm-lockfile-verification-memory--2026-10-17
It contains the manifests, pnpm-workspace.yaml and pnpm-lock.yaml of a real 11-project workspace (1,798 lockfile entries, trustPolicy: no-downgrade, minimumReleaseAge: 1440), with the source removed. It needs Docker:
./repro.sh # pnpm 12.14.0: exit 137
PNPM_VERSION=11.28.4 ./repro.sh # exit 0
MALLOC_ARENA_MAX=2 ./repro.sh # pnpm 12.14.0: exit 0repro.sh bumps one catalog specifier, then runs Renovate's relock in a node:24 container capped at 2.25 GB, with a cold store and cache:
CI=true pnpm install --lockfile-only --recursive --ignore-scripts --ignore-pnpmfile --no-frozen-lockfile
Expected behavior
The relock completes under 2.25 GB, as it does on 11.28.4.
Actual behavior
The process is killed during supply-chain verification:
? Verifying lockfile against supply-chain policies (1798 entries)...
bash: line 10: 40 Killed CI=true pnpm install --lockfile-only --recursive --ignore-scripts --ignore-pnpmfile --no-frozen-lockfile
repro.sh: container exited 137, OOM-killed under the 2250m cap
Peak RSS, summed over the container's processes and sampled every 200 ms, on a Docker VM with 12 CPUs:
| Run | 11.28.4 | 12.14.0 | 12.14.0, MALLOC_ARENA_MAX=2 |
|---|---|---|---|
| arm64, no cap (×2) | 2.02, 1.96 GB | 3.11, 3.33 GB | 1.49, 1.53 GB |
| arm64, 2.25 GB cap (×3) | 1.91, 1.97, 1.85 GB | killed ×3 | 1.45, 1.63, 1.55 GB |
| amd64, 2.25 GB cap | 1.97 GB | killed | 1.54 GB |
Additional information
- This follows up Lockfile supply-chain verification peaks at ~2.3 GB RSS for 1,400 entries on pnpm 11 and 12, OOM-killing Mend-hosted Renovate #16656. fix(verify): stop lockfile verification from keeping every version's manifest #16668 (in 12.11.0) brought this workspace down from 4.45 GB on 12.10.1 to 2.94 GB on 12.11.2 (macOS), but 12.x still peaks well above 11.28.4 here.
trustPolicyis the trigger. With onlyminimumReleaseAgeset, 12.14.0 peaked below 11.28.4 in my runs.MALLOC_ARENA_MAX=2cut the peak roughly in half on every dependency graph I tried, which fits the glibc arena fragmentation mentioned in Lockfile supply-chain verification peaks at ~2.3 GB RSS for 1,400 entries on pnpm 11 and 12, OOM-killing Mend-hosted Renovate #16656. Whether 12 is worse than 11 depends on the graph: on a 40-package set of stable releases, 11 peaked higher.- Why it matters: Mend-hosted Renovate runs Renovate and pnpm in one 3 GB VM. On 12.x every relock of this workspace is killed at 3.0 of 3.0 GB, and a repository can't set
MALLOC_ARENA_MAXthere. - My guess at a fix: pnpm limiting malloc arenas itself, or switching allocators.
Node.js version
24.22.0 (node:24 image)
Operating System
Linux
Activity
github-actions commentedon Oct 17, 2026
@jd-solanki, are you planning to open a pull request for this? If so, reply here and a maintainer will assign the issue to you, so nobody else starts on the same fix.
shahinsamiur commentedon Oct 17, 2026
Hi,
I'd like to investigate this issue and propose a fix. I'll start by looking into the lockfile supply-chain-verification path to find what causes the excessive memory usage increase in pnpm 12.14.0 and then try implementing a minimal fix that can be verified on the provided reproduction. Please assign this issue to me.
zkochan commentedon Oct 18, 2026
Update: I changed the approach in #17081. A process-wide arena cap slowed warm installs in our benchmark, so the PR now targets the decode path and leaves glibc's settings alone:
On your repro (cold cache, 32-CPU Linux machine), peak RSS fell from 2.6 to 3.7 GB to 1.8 to 2.0 GB with default arenas. Under a 2.25 GB cgroup cap, 12.14.0 was killed and this build finished at 1.88 GB. I could not test arm64; numbers from there would be welcome once a build is available.
Written by an agent (Claude Code, claude-opus-5-5).
fix(resolving-npm-resolver): decode registry metadata on a dedicated …
fix(resolving-npm-resolver): decode registry metadata on a dedicated …
kristoferma commentedon Oct 22, 2026
Thanks for this one. These are Linux numbers from the workspace in #16656, which I had measured on macOS. I ran the same
pnpm install --lockfile-only --recursive --ignore-scripts --ignore-pnpmfile --no-frozen-lockfilewithminimumReleaseAge: 1440andtrustPolicy: no-downgrade, a cold cache and store, and one direct dependency changed. The image wasnode:24-bookworm(glibc 2.36, aarch64) and the lockfile has 1,394 entries.Verification time is about the same, roughly 8.5 s. The peak also stopped swinging between runs. That is enough for us to move the policies back into
pnpm-workspace.yamland let Renovate verify inside Mend's 3 GB microVM again.Written by an agent (Claude Code, claude-opus-5-5).
Update pnpm to v12.15.0 (#2046)
Update pnpm to v12.15.0 (#2046)