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

[DTesch-Reem]

Environment

---

• Operating System: Linux
• Node Version: v18.19.0
• Nuxt Version: 3.10.0
• CLI Version: 3.10.0
• Nitro Version: 2.8.1
• Package Manager: [email protected]
• Builder: -
• User Config: extends, modules, css, app, devtools, multiCache, experimental, colorMode, runtimeConfig, graphql-client, ui, $development, nitro
• Runtime Modules: [email protected], [email protected], @nuxt/[email protected]
• Build Modules: -

---

Reproduction

I am using ddev with nginx to get ssl on local environment. (ddev npm run dev)
After 10-15 saves, when using the HMR with the Dev-Server I get this error:

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0xb7f974 node::Abort() [/usr/bin/node]
2: 0xa97f08 [/usr/bin/node]
3: 0xd40e78 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
4: 0xd41048 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
5: 0xf1f5fc [/usr/bin/node]
6: 0xf20264 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/bin/node]
7: 0xf307ac [/usr/bin/node]
8: 0xf31370 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/bin/node]
9: 0xf0d718 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
10: 0xf0e6f0 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
11: 0xef1380 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/bin/node]
12: 0x1297a34 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/bin/node]
13: 0x167c4ec [/usr/bin/node]

Describe the bug

Running the dev-Server behind a reverse proxy (nginx) and using HMR crashes the development server after some saves (10-15).
Only fix is to restart the server.

Additional context

No response

Logs

No response

[github-actions]

Would you be able to provide a reproduction? 🙏

More info

Why do I need to provide a reproduction?

Reproductions make it possible for us to triage and fix issues quickly with a relatively small team. It helps us discover the source of the problem, and also can reveal assumptions you or we might be making.

What will happen?

If you've provided a reproduction, we'll remove the label and try to reproduce the issue. If we can, we'll mark it as a bug and prioritize it based on its severity and how many people we think it might affect.

If needs reproduction labeled issues don't receive any substantial activity (e.g., new comments featuring a reproduction link), we'll close them. That's not because we don't care! At any point, feel free to comment with a reproduction and we'll reopen it.

How can I create a reproduction?

We have a couple of templates for starting with a minimal reproduction:

👉 https://stackblitz.com/github/nuxt/starter/tree/v3-stackblitz
👉 https://codesandbox.io/s/github/nuxt/starter/v3-codesandbox

A public GitHub repository is also perfect. 👌

Please ensure that the reproduction is as minimal as possible. See more details in our guide.

You might also find these other articles interesting and/or helpful:

• The Importance of Reproductions
• How to Generate a Minimal, Complete, and Verifiable Example

[boboldehampsink]

Seeing this too with 3.10+

[alexrodriguezjob]

We are having the same issue, couln't replicate in dev/staging and in production we have an absurd increase of memory

[daniluk4000]

We are having the same issue, couln't replicate in dev/staging and in production we have an absurd increase of memory

Jesus christ.

I'll share our stats then. We have semi-highload website with several replicas of Nuxt. All of them go to ~500-600MB of memory, which is even higher we were on Nuxt 2. On Staging we have no higher than 300MB, with medium at ~200-250MB. Nuxt 2 were more stable for me on memory. Sadly we went straight to Nuxt 3.10 (were upgrading) so I can't say if it was better.

But at least this 600MB is stable. It doesn't go much higher.

[daniluk4000]

Our heavy spike was caused by asyncContext + timeout in useFetch/ofetch (unjs/ofetch#361, unjs/ofetch#369)

[andrevferreiraa]

Got the same issue but when generating the pages

[danielroe]

Let's track in #26798.