nuxt generate memory leak

[andrewharvey]

Versions

• nuxt: 2.14.1
• node: v14.7.0

Reproduction

I'm using nuxt generate with the memory benchmarking from #7412 (comment).

I've reduced the generate.concurrency down to 1 and I can see in the logs that after "Generating pages with full static mode" it start's going through my pages and the heap memory just keeps on growing.

After about 100 pages generated it runs out of heap memory FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory.

I'm using 3GB of heap memory with node --max_old_space_size=3072 ./node_modules/.bin/nuxt generate, sure I could increase this but with hundreds of pages it's not scalable.

This wasn't happening in the older version of nuxt 2.12.2

What is Expected?

I expect that generating pages would have roughly flat memory usage and not keep on growing with each generated page.

What is actually happening?

Memory usage keeps growing with each generated page.

[andrewharvey]

I discovered this only happens on the first run (but reliably on the first fresh run), if after the crash due to out of memory I run the same generate command again, heap usage hovers around 500MB and stays there throughout each generated route.

So my weird workaround is to let it crash and run again.

[pi0]

Hi @andrewharvey. Do you have a reproduction repo or if hard possibily privately sharing repo?

[andrewharvey]

Hi @andrewharvey. Do you have a reproduction repo or if hard possibily privately sharing repo?

I'll try to cut it down into something reproducible, but for a large application this isn't straightforward.

I tried running an allocation timeline profile, but because of the resources required just to capture it I could only capture a few seconds, and to be honest I can't really understand it

[andrewharvey]

this sampling profile seems to show it's mostly in an anonymous function in async function createApp(ssrContext, config = {}) {.

Not that this probably helps much without a minimal replication....

[ghost]

Same problem! Nuxt generates 1/5 pages, freezes, eats up all memory and crashes. Last normally working version for me 2.12+

[Spreizu]

I also encountered this problem while first upgrading to Nuxt 2.13 (Javascript heap out of memory while generating pages). For me, this happened for 2 reasons:

1. A very large payload was manually specified to the route (~6 MB);
2. $route object was passed to the store commit call as a parameter inside page asyncData
   After optimizing the payload size and refactoring the store mutation logic, this issue disappeared. However, the root cause is still unknown.

[AliasIO]

I'm running into this issue as well. My repository is public: https://github.com/AliasIO/wappalyzer.com

<--- Last few GCs --->

[54002:0x102409000]  1097925 ms: Mark-sweep 3879.9 (4117.9) -> 3874.1 (4111.7) MB, 2800.7 / 0.0 ms  (average mu = 0.138, current mu = 0.022) allocation failure scavenge might not succeed
[54002:0x102409000]  1098012 ms: Scavenge 3878.3 (4111.7) -> 3875.3 (4111.7) MB, 42.2 / 0.0 ms  (average mu = 0.138, current mu = 0.022) allocation failure 
[54002:0x102409000]  1098090 ms: Scavenge 3891.0 (4114.3) -> 3879.6 (4115.8) MB, 19.7 / 0.0 ms  (average mu = 0.138, current mu = 0.022) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x10072e699]
Security context: 0x00a190b408a1 <JSObject>
    1: join [0xa190b51239](this=0x00a1e3304fe1 <JSArray[39]>,0x00a113300729 <String[#0]: >)
    2: intoTokens [0xa1effb7e09] [/Users/elbert/Sites/wappalyzer/v4/frontend/node_modules/clean-css/lib/tokenizer/tokenize.js:~80] [pc=0x3b7f26fab657](this=0x00a170d44cf1 <GlobalObject Object map = 0xa1ce51f2e1>,0x00a259d00111 <Very long string[386516]>,0x00a2579c9251 <O...

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

Writing Node.js report to file: report.20200831.135051.54002.0.001.json
Node.js report completed
 1: 0x100b6a52a node::Abort() (.cold.1) [/usr/local/Cellar/node/12.12.0/bin/node]
 2: 0x100081f70 node::FatalError(char const*, char const*) [/usr/local/Cellar/node/12.12.0/bin/node]
 3: 0x100082098 node::OnFatalError(char const*, char const*) [/usr/local/Cellar/node/12.12.0/bin/node]
 4: 0x10017461d v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node/12.12.0/bin/node]
 5: 0x1001745c7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node/12.12.0/bin/node]
 6: 0x10028a569 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/Cellar/node/12.12.0/bin/node]
 7: 0x10028b8ee v8::internal::Heap::MarkCompactPrologue() [/usr/local/Cellar/node/12.12.0/bin/node]
 8: 0x1002894eb v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/Cellar/node/12.12.0/bin/node]
 9: 0x100287f93 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/Cellar/node/12.12.0/bin/node]
10: 0x10028f6da v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/usr/local/Cellar/node/12.12.0/bin/node]
11: 0x10028fbd0 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/usr/local/Cellar/node/12.12.0/bin/node]
12: 0x10026d8c6 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType) [/usr/local/Cellar/node/12.12.0/bin/node]
13: 0x1004bc4ee v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/Cellar/node/12.12.0/bin/node]
14: 0x10072e699 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/usr/local/Cellar/node/12.12.0/bin/node]
15: 0x100742e9a Builtins_ArrayPrototypeJoin [/usr/local/Cellar/node/12.12.0/bin/node]
16: 0x3b7f26fab657 
17: 0x3b7f26fac5d4

[Atinux]

Hi, you could try disabling the crawler?

export default {
  generate: {
    crawler: false
  }
}

[AliasIO]

@Atinux That fixes it, no issue on 2.14 with crawler set to false. I can also confirm it was working fine on 2.12 without disabling the crawler.

[evilsprut]

Hi, you could try disabling the crawler?

@Atinux Unfortunately nothing has changed

UPD:

After all, there was an error in my code...

In my case, the problem arose because in one of the components, the name of the nested component and the name of the exported class coincided.

import { Component, Vue } from 'nuxt-property-decorator';

@Component({
  components: {
    Blablabla: () => import('@/components/Blablabla.vue'), // Here 
  },
})
export default class Blablabla extends Vue {} // And here 😁

I have no idea why it worked normally in on Nuxt 2.12+. Maybe it'll help somebody.

[AliasIO]

@Atinux I thought disabling the crawler fixed it but I'm having the same issue again. I downgraded to 2.12 for now.

[gabrielsze]

Having the same issue when i upgraded from 2.13 to 2.14, fails at nuxt generate with/without target static.

It seems to work for fully static if i cancel and run the command again (2 tries to work every time), but without full static (original legacy static) it doesn't seem to work and hangs.

Not sure if related but #5546,

Downgraded to 2.13 for now

[gryphonmyers]

I just spent a whole day trying to optimize what I thought was a leaky application. I'm increasingly certain that the problem lies with Nuxt, especially hearing I'm not the only one. Over the course of debugging memory consumption, I can see that even after the generate process has completed, our generate process leaves over 2GB sitting in heap.

Our application is fetching fairly large payloads in the fetch method, across most routes of a fairly large site (many hundreds of routes). If I limit the amount of data that is being fetched here, the problem is less noticeable. Thus the problem seems to scale both with the amount of data being fetched and the number of routes being generated.

[andrewharvey]

@pi0 I spent a few hours reducing my project to a minimally reproducing example.

https://github.com/andrewharvey/nuxt-bug-7855

Running yarn run generate the memory will keep growing for each page and never come down, all the way until running out of space. Increasing max_old_space_size might buy you a couple extra pages, but that's not scalable and doesn't address the root cause.

There are still a few pieces but I've hit the point where if I take something out I don't see the issue anymore, so it's hard to work out what exactly is causing it.

UPDATE: though if I replace https://github.com/andrewharvey/nuxt-bug-7855/blob/master/store/index.js#L15 with the similar bit from earlier in the file then looks like the issue goes away...

[stale]

Thanks for your contribution to Nuxt.js!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of nuxt-edge
2. Comment the steps to reproduce it

Issues that are labeled as pending will not be automatically marked as stale.

[andrewharvey]

@Stale I updated https://github.com/andrewharvey/nuxt-bug-7855 to use nuxt-edge and it's still reproducing as per #7855 (comment)

[stale]

Thanks for your contribution to Nuxt.js!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of nuxt-edge
2. Comment the steps to reproduce it

Issues that are labeled as pending will not be automatically marked as stale.

[andrewharvey]

@Stale Yes I can still replicate, updated nuxt-edge to latest. However the workaround does seem to make a difference, so that might be helpful for anyone interested in looking at this.

[Atinux]

Sorry for the delay, I have this issue in my todo list since it could affect also Nuxt 3.

[danielroe]

I'm looking into this and will update this comment with my current thinking, which undoubtedly will change.

I can replicate this issue using the repo above - with the CLI - as long as there is an initial build (you can also force this on subsequent builds by setting generate.cache to be false). However, running generation programmatically does not appear to result in a memory leak (and is also considerably faster):

const { Builder, Generator, Nuxt } = require('nuxt-edge')
const config = require('./nuxt.config.js')

async function main() {
    const nuxt = new Nuxt({
        ...config,
        dev: false
    })
    await nuxt.ready()
    const builder = new Builder(nuxt)
    const generator = new Generator(nuxt, builder)
    await generator.generate()

}

main()

[danielroe]

@andrewharvey To add to the above, as far as I can tell the specific memory leak you've identified is caused by Vuetify rather than Nuxt (cc: @kevinmarrec). I haven't been able to confirm that in your case @AliasIO - if you can get in contact with an API key so I can generate routes locally for your site I'd be grateful.

If anyone in this thread who has encountered a memory leak like this and is not using Vuetify I'd welcome a reproduction or more information.

[maou-shonen]

I have recently experienced the same problem in a corporate environment,
But I don't have this problem in my home environment,

I have tried using several new installations of the same version of ubuntu (20.04, 18.04), nodejs (v12, v14) and even docker,
I tried using a new installation of ubuntu, nodejs and even docker, but it didn't solve the problem.

The difference I can think of but can't test is,
The CPU that runs fine in my home is an AMD ryzen 1700,
The company uses an Intel I7 9700.

Sorry I'm not a front-end developer, so maybe that doesn't help.
This is probably just a report that the cause of the problem has nothing to do with the os version or the nodejs version.

Also lastly, I accidentally found that my company's windows 10 is working fine,
I'm currently working on windows.

[KHIT93]

I can confirm this with nuxt 2.14.12 on npm 7.4.3 and node 15.7.0

> kitecloud-website@1.0.0 dev
> nuxt

ℹ Using Tailwind CSS from ~/assets/css/tailwind.css                                                                                                                                                                                                       nuxt:tailwindcss 21:27:49
ℹ Merging Tailwind config from ~/tailwind.config.js                                                                                                                                                                                                       nuxt:tailwindcss 21:27:49
ℹ Parsed 1 files in 0,3 seconds                                                                                                                                                                                                                              @nuxt/content 21:27:50

   ╭───────────────────────────────────────────────────────╮
   │                                                       │
   │   Nuxt @ v2.14.12                                     │
   │                                                       │
   │   ▸ Environment: development                          │
   │   ▸ Rendering:   server-side                          │
   │   ▸ Target:      server                               │
   │                                                       │
   │   Listening: http://localhost:3000/                   │
   │                                                       │
   │   Tailwind Viewer: http://localhost:3000/_tailwind/   │
   │                                                       │
   ╰───────────────────────────────────────────────────────╯

ℹ Preparing project for development                                                                                                                                                                                                                                        21:27:51
ℹ Initial build may take a while                                                                                                                                                                                                                                           21:27:51
✔ Builder initialized                                                                                                                                                                                                                                                      21:27:51
✔ Nuxt files generated                                                                                                                                                                                                                                                     21:27:51

✔ Client
  Compiled successfully in 14.75s

✔ Server
  Compiled successfully in 14.34s

ℹ Waiting for file changes                                                                                                                                                                                                                                                 21:28:06
ℹ Memory usage: 990 MB (RSS: 1.16 GB)                                                                                                                                                                                                                                      21:28:06
ℹ Listening on: http://localhost:3000/                                                                                                                                                                                                                                     21:28:06

<--- Last few GCs --->

[12012:0x5e89f40]   213608 ms: Scavenge 3887.4 (4117.0) -> 3882.9 (4120.2) MB, 9.7 / 0.0 ms  (average mu = 0.963, current mu = 0.971) task 
[12012:0x5e89f40]   214367 ms: Scavenge 3896.6 (4125.2) -> 3892.1 (4129.0) MB, 9.5 / 0.0 ms  (average mu = 0.963, current mu = 0.971) task 
[12012:0x5e89f40]   216510 ms: Mark-sweep 3906.3 (4134.0) -> 3877.2 (4138.2) MB, 1362.1 / 0.2 ms  (average mu = 0.937, current mu = 0.901) task scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
Segmentation fault (core dumped)
npm ERR! code 139
npm ERR! path /home/kenneth/Code/kitecloud-website
npm ERR! command failed
npm ERR! command sh -c nuxt

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/kenneth/.npm/_logs/2021-01-27T20_31_28_575Z-debug.log

I can start the dev server and then work with the "root" page of my app, but as soon as I switch to different page, it stops working.
Everything worked fine until yesterday, but then today, I started to have this issue
I have tried to delete the .nuxt folder to see if maybe something in there was not correctly rebuilt, but no luck

[danielroe]

@KHIT93 your issue is different from this one, and likely fixed in nuxt-edge - see #8522 - do try and see if it solves the issue for you 😊

[KHIT93]

@danielroe Unfortunately switching to nuxt-edge did not make a difference. Even downgraded from Node 15.x to Node 14.x and reinstalled all npm packages for the project. But now even the index page refuses to load.
Perhaps this would deserve a separate issue since it is not the same issue as discussed here :)

[MartinWeise]

Encountered the same problem with a standard application, nuxt will eat up the whole RAM and crashes when you allocate more using e.g. https://stackoverflow.com/questions/52205500/nuxt-generate-fatal-error-ineffective-mark-compacts-near-heap-limit-allocation

[danielroe]

@MartinWeise A reproduction would be appreciated 🙃

[adam-knights]

@danielroe I got this error in a new nuxt app, it also reproduces with nuxt-edge. I've stripped it down to a barebones reproduction: https://github.com/adam-knights/adam-nuxt-demo-heap

To reproduce just run docker build -m 4gb .

You mentioned something around a build and then generate being an issue, and thats the case in the Dockerfile here.

I also created a new app using an older create nuxt app template and can confirm I don't see the issue in 2.12.2

Screenshot of create nuxt app run that made the barebones.

[danielroe]

@adam-knights I can't reproduce a memory leak with that project.

[mirkofisic]

NuxtJS version v2.16.0-26938120.9247190c huge memory leak in dev mode and also in prod, I think here is problem related with nuxt link and nuxt i18n strategy prefix mode, this is rather unstable and I can say that it is unusable at the moment!

<--- Last few GCs --->

[13848:00000165401FA9E0] 3398103 ms: Mark-sweep 2044.3 (2051.6) -> 2044.2 (2052.1) MB, 1902.7 / 0.1 ms (average mu = 0.072, current mu = 0.001) allocation failure scavenge might not succeed
[13848:00000165401FA9E0] 3399838 ms: Mark-sweep 2044.8 (2052.1) -> 2044.5 (2052.4) MB, 1734.7 / 0.0 ms (average mu = 0.038, current mu = 0.000) allocation failure scavenge might not succeed

<--- JS stacktrace --->

==== JS stack trace =========================================

0: ExitFrame [pc: 00007FF66D4DB49D]

Security context: 0x0064e70c08d1
1: initWatch(aka initWatch) [0000000EB1034241] [C:\projects\nuxtjs\esapp\node_modules\vue\dist\vue.runtime.common.dev.js:~4863] [pc=00000249F5717C5D](this=0x023ab23c04b1 ,0x00e15827ffe9 ,0x03748bec3fd1 )
2: initState(aka initState) [0000000EB1033FE1] [C:\projects\nuxtjs...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF66C8C5F0F napi_wrap+114095
2: 00007FF66C870B96 v8::base::CPU::has_sse+66998
3: 00007FF66C871996 v8::base::CPU::has_sse+70582
4: 00007FF66D086E9E v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF66D06EF71 v8::SharedArrayBuffer::Externalize+833
6: 00007FF66CF3B1DC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436
7: 00007FF66CF46410 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
8: 00007FF66CF42F34 v8::internal::Heap::PageFlagsAreConsistent+3204
9: 00007FF66CF38733 v8::internal::Heap::CollectGarbage+1283
10: 00007FF66CF36DA4 v8::internal::Heap::AddRetainedMap+2452
11: 00007FF66CF580ED v8::internal::Factory::NewFillerObject+61
12: 00007FF66CCBE231 v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1665
13: 00007FF66D4DB49D v8::internal::SetupIsolateDelegate::SetupHeap+546637
14: 00000249F5717C5D

[danielroe]

@mirkofisic Always happy to take a look. Could you create a new issue with a reproduction please? 🙏

[mirkofisic]

@mirkofisic Always happy to take a look. Could you create a new issue with a reproduction please? 🙏

I am very busy but I will try to explain details:

I have 2 subpages
pages > manager > trainings(inside trainings I have index and _id)
_id represent id of the training in database alsmost every time if I changed url manually in the browser I got memory leak.
/manager/trainings/1234 if change to 0(indicates to create new training video) and press enter, or any other Id I got memory leak.

[yoyo837]

Same here

[dev-core] <--- Last few GCs --->
[dev-core]
[dev-core] [5956:000001F35933F3B0] 14859671 ms: Mark-sweep 2030.7 (2081.3) -> 2019.0 (2085.3) MB, 925.3 / 3.9 ms  (average mu = 0.909, current mu = 0.239) allocation failure scavenge might not succeed
[5956:000001F35933F3B0] 14861553 ms: Mark-sweep (reduce) 2035.1 (2085.3) -> 2023.5 (2089.3) MB, 1820.8 / 4.2 ms  (+ 0.1 ms in 256 steps since 
start of marking, biggest step 0.0 ms, walltime since start of marking 1882 ms) (average mu = 0.778, current mu =
[dev-core]
[dev-core] <--- JS stacktrace --->
[dev-core]
[dev-core] FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
[dev-core]  1: 00007FF7F32F481F napi_wrap+110783
[dev-core]  2: 00007FF7F3297F26 v8::base::CPU::has_sse+61862
[dev-core]  3: 00007FF7F3298E26 node::OnFatalError+294
[dev-core]  4: 00007FF7F3B723BE v8::Isolate::ReportExternalAllocationLimitReached+94
[dev-core]  5: 00007FF7F3B5718D v8::SharedArrayBuffer::Externalize+781
[dev-core]  6: 00007FF7F3A002CC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1516
[dev-core]  7: 00007FF7F39EAD5B v8::internal::NativeContextInferrer::Infer+59739
[dev-core]  8: 00007FF7F39D003F v8::internal::MarkingWorklists::SwitchToContextSlow+56959
[dev-core]  9: 00007FF7F39E3D1B v8::internal::NativeContextInferrer::Infer+31003
[dev-core] 10: 00007FF7F39DADFD v8::internal::MarkCompactCollector::EnsureSweepingCompleted+6285
[dev-core] 11: 00007FF7F39E2F6E v8::internal::NativeContextInferrer::Infer+27502
[dev-core] 12: 00007FF7F39E6FBB v8::internal::NativeContextInferrer::Infer+43963
[dev-core] 13: 00007FF7F39F09B2 v8::internal::ItemParallelJob::Task::RunInternal+18
[dev-core] 14: 00007FF7F39F0941 v8::internal::ItemParallelJob::Run+641
[dev-core] 15: 00007FF7F39C3FC3 v8::internal::MarkingWorklists::SwitchToContextSlow+7683
16: 00007FF7F39DB2AC v8::internal::MarkCompactCollector::EnsureSweepingCompleted+7484
[dev-core] 17: 00007FF7F39D9AE4 v8::internal::MarkCompactCollector::EnsureSweepingCompleted+1396
[dev-core] 18: 00007FF7F39D7668 v8::internal::MarkingWorklists::SwitchToContextSlow+87208
[dev-core] 19: 00007FF7F3A060B1 v8::internal::Heap::LeftTrimFixedArray+929
[dev-core] 20: 00007FF7F3A081A5 v8::internal::Heap::PageFlagsAreConsistent+789
[dev-core] 21: 00007FF7F39FD3D1 v8::internal::Heap::CollectGarbage+2049
[dev-core] 22: 00007FF7F39FB5D5 v8::internal::Heap::AllocateExternalBackingStore+1349
[dev-core] 23: 00007FF7F3A1BA3B v8::internal::Factory::NewFillerObject+203
24: 00007FF7F374A0B1 v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1409
[dev-core] 25: 00007FF7F3BFB27D v8::internal::SetupIsolateDelegate::SetupHeap+465325
[dev-core] 26: 0000036B0C34E05D
[dev-core] [nodemon] app crashed - waiting for file changes before starting...

[freefri]

Hoping that this may help others:
in our case the memory leak was caused by global Vue.mixin({...}) inside custom plugins.

The correct implementation of a global mixin is here:
https://nuxtjs.org/docs/2.x/directory-structure/plugins/#global-mixins

if (!Vue.__my_mixin__) {
  Vue.__my_mixin__ = true
  Vue.mixin({ ... }) // Set up your mixin then
}

I would like to call attention here, is this maybe something that Nuxt or Vue should do automatically?
I do not think we should trust developers to read the whole documentation of the framework before implementing a global mixin properly. I would say a run time warning in console, a build time error or a linter error could be implemented. If this causes severe memory leaks, why there is not a way of applying some kind of singleton pattern so a mixin cannot be defined more than one time. Is there a reason why it should be allowed to define a mixin more than once?

[erkand-imeri]

Hello all, i am having memory leak in Nuxt.js in production. It's crazy, i looked at the code and nothing that indicates, i migrated from Laravel/Vue to Nuxt.js. The Vue.js code is essentially the same. I think the problem is within Nuxt.js.

[Mobeidat]

I'm facing the same issue guys, almost spent 3 days without any good luck to find a solution

[dsolanorush]

After 3 days of attempting some of the solutions outlined above, lots of additional searching and trial/error (and lots of cussing), the culprit for me was a watch being initiated within a global composable on server side, thus being initiated on every single SSG route. Wrapping the watcher with process.client condition fixed all my problems.

[h4ckthepl4net]

I don't know if it's related to your issue, but we have 2GB RAM server which has 1 GB of swap space, we've been building our application with "nuxt build" successfully for a very long time (with a very big RAM usage though + running other processes with pm2), but yesterday after updating some of our project dependencies, we've encountered a problem with build, the build was not passing caused by too much RAM usage (even the swap space was full, and all pm2 processes were stopped). It was fixed by setting --max-old-space-size=2048 (with " export NODE_OPTIONS="--max-old-space-size=2048" "). We're using "nuxt build" command.

[EDIT] after a few tests it turns out that, it is fixed only by using "--max-old-space-size=2048" and stopped pm2 all processes

[danielroe]

We are approaching the Nuxt 2 EOL date (June 30, 2024) - see this article for more information. This is advance warning that I'm going to close this issue then, as it's currently marked as a Nuxt 2 related bug.

If it's a critical or security issue, please do comment and let me know, in case it is possible to address it before the EOL date.

If it's a an issue you think is relevant for Nuxt 3, please feel free to open a fresh issue (or just comment here so I can update labels, etc.). 🙏

Thank you for your understanding and for your contribution to Nuxt. ❤️

[danielroe]

It's the day, at last. Nuxt 2 is now marked end-of-life.

My apologies we never got round to resolving this bug in the 2.x branch, but we do have to draw a line somewhere. Again, if you think this is still relevant for Nuxt going forward, please feel free to open a fresh issue (or just comment here so I can update labels, etc.). 🙏