Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

[bhavesh2510]

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

9.1.0

Which area(s) of pnpm are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

Reproduction steps

i'm using NX workspace and using pnpm to install dependencies
Build fails on pipeline
just FYI --max-size=3017 is not working, tried everything but couldn't make it work
However on local machine it works fine but on bitbucket pipeline it breaks

"build:manager": "nx run manager-dashboard:build --prod --skip-nx-cache --configuration=prod",

Here is the step

• step:
  name: Trigger pnpm build test
  size: 2x
  image: node:18.16.0
  script:
  - corepack enable
  - corepack prepare pnpm@latest-9 --activate
  - pnpm install
  - pnpm build:manager
  caches:
  - pnpm

Describe the Bug

<--- Last few GCs --->
[328:0x6242d20] 12010 ms: Mark-sweep (reduce) 529.7 (541.8) -> 528.7 (540.8) MB, 301.9 / 0.0 ms (average mu = 0.108, current mu = 0.025) allocation failure; scavenge might not succeed
[328:0x6242d20] 12017 ms: Scavenge (reduce) 530.2 (541.0) -> 529.6 (541.0) MB, 1.4 / 0.0 ms (average mu = 0.108, current mu = 0.025) allocation failure;
[328:0x6242d20] 12024 ms: Scavenge (reduce) 530.2 (541.0) -> 529.9 (541.5) MB, 4.3 / 0.0 ms (average mu = 0.108, current mu = 0.025) allocation failure;
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0xb7a940 node::Abort() [/usr/local/bin/node]
2: 0xa8e823 [/usr/local/bin/node]
3: 0xd5c940 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
4: 0xd5cce7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
5: 0xf3a3e5 [/usr/local/bin/node]
6: 0xf3b2e8 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/local/bin/node]
7: 0xf4b7f3 [/usr/local/bin/node]
8: 0xf4c668 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
9: 0xf26fce v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
10: 0xf28397 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
11: 0xf0956a v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
12: 0x12ce7af v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
13: 0x16fb6b9 [/usr/local/bin/node]

Expected Behavior

dont know what am i missing here

Which Node.js version are you using?

18.16.0

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

No response

[zkochan]

Should be fixed by #8060

[zkochan]

🚢 9.1.1

[bhavesh2510]

@zkochan this issue still persists even after using pnpm version 9.1.1

[zkochan]

How can I reproduce this? Is the project open source?

[bhavesh2510]

@zkochan it is not opensource, im using nx monorepo with node version 18.16.0 & pnpm version 9.1.1
i will try to come with some sample project if possible

[sammarks]

FWIW I am unfortunately not able to provide the source for my example either, but I have been doing a bit of debugging on my end.

On my machine, the process doesn't get to the point of running out of memory, but does peg the CPU.

In my case, inside resolvePeersOfChildren, calculateDepPaths has a length of 92 for one specific package (I'm guessing the package itself is irrelevant as it depends on the packages that depend on it), which seems a lot longer than the rest. That calls analyzeGraph from graph-cycles with 156 nodes, and ~a quarter of those nodes having ~20-30 dependencies. The call to analyzeGraph does eventually finish without running out of memory, but takes several minutes to complete.

I verified this by installing v1.2.1 of graph-cycles separately and passing it the same payload.

Not sure if there's a way to reduce the size of the graph passed to graph-cycles, or if there's a way to improve the performance of graph-cycles.

Our environment is a large monorepo with ~200 interconnected packages, with a lot of them referencing the others as peer dependencies (version specifier "<1.0.0" for all of the interrelated peers). The installation inside the main monorepo succeeds without any slowness, but running an installation inside another much smaller monorepo that depends on a lot of the packages from the larger monorepo is the one that stalls. The packages from the main monorepo are being downloaded from a registry instead of any local workspace linking.

So I would imagine this might be reproducible by creating a smaller monorepo (5 packages) that depend on other packages with a lot of peer dependencies to drive the size of that graph up.

[smart]

Chiming in to say we're experiencing this using github actions on a turborepo monorepo building a sveltekit app on pnpm 9.1.1.

✓ 1789 modules transformed.
rendering chunks...
<--- Last few GCs --->
[5527:0x661a640] 68118 ms: Mark-Compact (reduce) 2035.4 (2076.3) -> 2035.3 (2076.8) MB, 1244.63 / 0.02 ms (+ 84.4 ms in 7 steps since start of marking, biggest step 26.4 ms, walltime since start of marking 1353 ms) (average mu = 0.300, current mu = 0.[5527:0x661a640] 69962 ms: Mark-Compact (reduce) 2041.8 (2082.5) -> 2040.6 (2082.4) MB, 1834.44 / 0.00 ms (average mu = 0.153, current mu = 0.006) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0xb84bd6 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
2: 0xefec30 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
3: 0xefef17 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
4: 0x1110925 [node]
5: 0x11287a8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
6: 0x10fe8c1 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
7: 0x10ffa55 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
8: 0x10dd0a6 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
9: 0x1537e36 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
10: 0x7fb92ce99ef6
Aborted (core dumped)
 ELIFECYCLE  Command failed with exit code 134.

[smart]

Just a follow up to this as I continue to debug. Here is my github actions file. I tried not building through turbo and going directly to build within the app directory.

jobs:
build:
name: Build and Test
timeout-minutes: 15
runs-on: ubuntu-latest

steps:
  - name: Check out code
    uses: actions/checkout@v4
    with:
      fetch-depth: 2

  - uses: pnpm/action-setup@v4
    with:
      version: 9.1.1

  - name: Setup Node.js environment
    uses: actions/setup-node@v4
    with:
      node-version: 20
      cache: 'pnpm'

  - name: Install dependencies
    run: pnpm install --no-frozen-lockfile

  - name: Install playwright browsers
    run: pnpx playwright install --with-deps

  - name: Build
    working-directory: ./apps/web
    run: pnpm build 

  - name: Test
    working-directory: ./apps/web
    run: pnpm test

Still resulted in:
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0xb84bd6 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
2: 0xefec30 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
3: 0xefef17 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
4: 0x1110925 [node]
5: 0x11287a8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
6: 0x10fe8c1 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
7: 0x10ffa55 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
8: 0x10dd0a6 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
9: 0x1537fe1 v8::internal::Runtime_AllocateInOldGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
10: 0x7fe059e99ef6
Aborted (core dumped)
 ELIFECYCLE  Command failed with exit code 134.

[zkochan]

I have reduced memory consumption in this PR: #8084

I don't know if it will be enough for you all. Maybe you could try to build pnpm from that branch and see if it helps.

[zkochan]

Try 9.1.2

[bhavesh2510]

@zkochan i'm still facing this issue, happens on bitbucket pipeline
sadly i can't provide sample code for this

- step: name: Trigger pnpm build test size: 2x image: node:18.16.0 script: - corepack enable - corepack prepare pnpm@latest - pnpm install - npm run build:manager caches: - pnpm

> nx run manager-dashboard:build:prod vite v4.3.9 building for production... transforming... replace "apps/manager-dashboard/src/environments/environment.ts" with "apps/manager-dashboard/src/environments/environment.prod.ts" replace "apps/manager-dashboard/src/environments/environment.ts" with "apps/manager-dashboard/src/environments/environment.prod.ts" replace "apps/manager-dashboard/src/environments/environment.ts" with "apps/manager-dashboard/src/environments/environment.prod.ts" replace "apps/manager-dashboard/src/environments/environment.ts" with "apps/manager-dashboard/src/environments/environment.prod.ts" replace "apps/manager-dashboard/src/environments/environment.ts" with "apps/manager-dashboard/src/environments/environment.prod.ts" replace "apps/manager-dashboard/src/environments/environment.ts" with "apps/manager-dashboard/src/environments/environment.prod.ts" replace "apps/manager-dashboard/src/environments/environment.ts" with "apps/manager-dashboard/src/environments/environment.prod.ts" node_modules/.pnpm/pdfjs-dist@3.11.174/node_modules/pdfjs-dist/build/pdf.js (1982:23) Use of eval in "node_modules/.pnpm/pdfjs-dist@3.11.174/node_modules/pdfjs-dist/build/pdf.js" is strongly discouraged as it poses security risks and may cause issues with minification. ✓ 7428 modules transformed. rendering chunks... <--- Last few GCs ---> [266:0x639cd20] 156539 ms: Mark-sweep 1942.0 (2101.7) -> 1917.0 (2094.2) MB, 1895.3 / 0.0 ms (average mu = 0.735, current mu = 0.547) allocation failure; scavenge might not succeed [266:0x639cd20] 158585 ms: Mark-sweep 1951.1 (2128.3) -> 1951.1 (2122.8) MB, 1974.5 / 0.0 ms (average mu = 0.552, current mu = 0.035) allocation failure; scavenge might not succeed <--- JS stacktrace ---> FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 1: 0xb7a940 node::Abort() [/usr/local/bin/node] 2: 0xa8e823 [/usr/local/bin/node] 3: 0xd5c940 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node] 4: 0xd5cce7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node] 5: 0xf3a3e5 [/usr/local/bin/node] 6: 0xf4c8cd v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node] 7: 0xf26fce v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node] 8: 0xf28397 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node] 9: 0xf088e0 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/usr/local/bin/node] 10: 0xf00354 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [/usr/local/bin/node] 11: 0xf02608 v8::internal::FactoryBase<v8::internal::Factory>::NewRawOneByteString(int, v8::internal::AllocationType) [/usr/local/bin/node] 12: 0x1042959 v8::internal::JsonParser<unsigned short>::MakeString(v8::internal::JsonString const&, v8::internal::Handle<v8::internal::String>) [/usr/local/bin/node] 13: 0x1044676 v8::internal::JsonParser<unsigned short>::ParseJsonValue() [/usr/local/bin/node] 14: 0x104515f v8::internal::JsonParser<unsigned short>::ParseJson() [/usr/local/bin/node] 15: 0xde2523 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node] 16: 0x16fb7b9 [/usr/local/bin/node]

[zkochan]

I believe this should do it: #8106

[zkochan]

Did one more memory optimization: #8109

I believe most of the issues will be solved in the next release.

[zkochan]

Try 9.1.3

[bhavesh2510]

@zkochan still same :(