FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory , on localhost

anish000kumar
0
anish000kumar
commented a year ago

Version

v1.4.0

Reproduction link

https://github.com/nuxt/nuxt.js

Steps to reproduce

Running npm run dev works fine, but on making any changes in any existing page, the localhost server crashes at 91% of the build step.

Here's the message receives on crash:

 WAIT  Compiling...                                                                                                                    14:30:29


  ████████████████████ 91% additional chunk assets processing
<--- Last few GCs --->

[9604:0x103000000]   130019 ms: Mark-sweep 1391.6 (1540.6) -> 1391.6 (1540.6) MB, 200.2 / 0.0 ms  allocation failure GC in old space requested
[9604:0x103000000]   130263 ms: Mark-sweep 1391.6 (1540.6) -> 1391.6 (1537.1) MB, 206.9 / 0.0 ms  last resort GC in old space requested
[9604:0x103000000]   130478 ms: Mark-sweep 1391.6 (1537.1) -> 1391.6 (1535.6) MB, 214.8 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 0x1fa090125ec1 <JSObject>
    0: builtin exit frame: parse(this=0x1fa090109021 <Object map = 0x1fa046302ba1>,0x1fa0d80cbe69 <Very long string[1580674]>)

    2: /* anonymous */(aka /* anonymous */) [/Users/ak/Documents/nuxt/nuxt-frontend/node_modules/vue-server-renderer/server-plugin.js:81] [bytecode=0x1fa02ff40979 offset=184](this=0x1fa0c9a02311 <undefined>,asset=0x1fa0be347c91 <Object map = 0x1fa0c62fe7f9>...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::Factory::NewRawOneByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 5: v8::internal::Handle<v8::internal::String> v8::internal::JsonParser<false>::SlowScanJsonString<v8::internal::SeqOneByteString, unsigned char>(v8::internal::Handle<v8::internal::String>, int, int) [/usr/local/bin/node]
 6: v8::internal::JsonParser<false>::ParseJsonValue() [/usr/local/bin/node]
 7: v8::internal::JsonParser<false>::ParseJsonArray() [/usr/local/bin/node]
 8: v8::internal::JsonParser<false>::ParseJsonValue() [/usr/local/bin/node]
 9: v8::internal::JsonParser<false>::ParseJsonObject() [/usr/local/bin/node]
10: v8::internal::JsonParser<false>::ParseJsonValue() [/usr/local/bin/node]
11: v8::internal::JsonParser<false>::ParseJson() [/usr/local/bin/node]
12: v8::internal::Builtin_Impl_JsonParse(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/bin/node]
13: 0x3b73ec08441d
[1]    9603 abort      npm run dev

I'm not sure what's causing this issue and any help would be really appreciated. I have looked into similar issues reported on github already, but none of those could actually lead me to the solution. Also, if there a way to run local server without hot module reloading ( with live reload), in case it's caused because of HMR?

What is expected ?

Hot module reloading should work on changes, without crashing the server

What is actually happening?

Localhost server crashes and build stops.

bug
0
aldarund
808
aldarund
commented a year ago

node version? happens every time?

0
XavierLeTohic
0
XavierLeTohic
commented a year ago

Same thing happening for me, sometimes.

Node 10.3.0
Nuxt 1.4.0 (happening also on Nuxt-edge)

0
anish000kumar
0
anish000kumar
commented a year ago

Yes happened everytime. Solved it by creating a custom script instead of nuxt start and allocating it max heap size of 3GB.

0
anish000kumar
0
anish000kumar
commented a year ago

here's the custom script, in case it helps someone else:

const {Nuxt, Builder} = require('nuxt')
const bodyParser = require('body-parser')
const session = require('express-session')
const app = require('express')()

// Body parser, to access req.body
app.use(bodyParser.json())

// Sessions to create req.session
app.use(session({
  secret: 'super-secret-key',
  resave: false,
  saveUninitialized: false,
  cookie: { maxAge: 60000 }
}))


// We instantiate Nuxt.js with the options
const isProd = process.env.NODE_ENV === 'production'
let config = require('./nuxt.config.js')
config.dev = !isProd
const nuxt = new Nuxt(config)
// No build in production
const promise = (isProd ? Promise.resolve() : new Builder(nuxt).build())
promise.then(() => {
  app.use(nuxt.render)
  app.listen(3000)
  console.log('Server is listening on http://localhost:3000')  // eslint-disable-line no-console
})
.catch((error) => {
  console.error(error)  // eslint-disable-line no-console
  process.exit(1)
})

And in package.json add this:

"scripts": {
    "serve": "node --max-old-space-size=3072 ./serve.js",
     ...

Then use npm run serve

0
appinteractive
6
appinteractive
commented a year ago

We have that same problem in our production app. Somehow the memory usage explodes and our app becomes unresponsive.

0
ryanrca
5
ryanrca
commented a year ago

We are having a similar issue. It seems random, one of our production containers crashes.
Is seems like our server is returning some large JSON objects.

This is our stack trace:

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

Security context: 0x2e216fda5ee1 <JSObject>
    0: builtin exit frame: parse(this=0x2e216fd89041 <Object map = 0x257018382ba1>,0x289dd282201 <Very long string[392019]>)

    1: transformResponse(aka transformResponse) [/app/node_modules/axios/lib/defaults.js:~56] [pc=0x22fafc4eb551](this=0x4151f882311 <undefined>,data=0x289dd282201 <Very long string[392019]>)
    2: arguments adaptor frame: 2->1
    4: transform(aka transform) [/app/node_...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x121a2cc [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [node]
 6: v8::internal::JsonParser<true>::ParseJsonArray() [node]
 7: v8::internal::JsonParser<true>::ParseJsonValue() [node]
 8: v8::internal::JsonParser<true>::ParseJsonObject() [node]
 9: v8::internal::JsonParser<true>::ParseJsonValue() [node]
10: v8::internal::JsonParser<true>::ParseJsonObject() [node]
11: v8::internal::JsonParser<true>::ParseJsonValue() [node]
12: v8::internal::JsonParser<true>::ParseJsonArray() [node]
13: v8::internal::JsonParser<true>::ParseJsonValue() [node]
14: v8::internal::JsonParser<true>::ParseJsonObject() [node]
15: v8::internal::JsonParser<true>::ParseJsonValue() [node]
16: v8::internal::JsonParser<true>::ParseJsonArray() [node]
17: v8::internal::JsonParser<true>::ParseJsonValue() [node]
18: v8::internal::JsonParser<true>::ParseJsonObject() [node]
19: v8::internal::JsonParser<true>::ParseJsonValue() [node]
20: v8::internal::JsonParser<true>::ParseJson() [node]
21: v8::internal::Builtin_JsonParse(int, v8::internal::Object**, v8::internal::Isolate*) [node]
22: 0x22fafb50441d
Aborted
0
RDeluxe
0
RDeluxe
commented a year ago

Same issue here, it's getting painful as the app grows

0
aldarund
808
aldarund
commented a year ago

Happened to me only once

0
appinteractive
6
appinteractive
commented a year ago

This is an app in production, when restarted the memory goes down but instantly grows upon crash.

e70c0fe2-3fd5-4b41-b45b-96bc059af2ed

0
jameshhood
0
jameshhood
commented a year ago

is there any work around or alternate solutions to keep this from happening? I have a production build on a limited environment and I definitely cant be having memory leaks and it crashing.

0
seanwash
0
seanwash
commented a year ago

@jameshhood I've been using https://github.com/HustleInc/regiment to at least tame things – while the root issue still exists, you can control how much ram is used and how process restarts happen. Using Regiment I've not noticed any connection times / app errors as a result, and I'm able to keep ram usage to a reasonable limit.

0
bok04
0
bok04
commented a year ago

@appinteractive thank you so much! this has helped me. This bug should definitely be looked at within Nuxt. Hopefully in version 2.0!

0
Atinux
26.4k
Atinux
commented a year ago

We will add more cases for memory profiling with Nuxt 2 (we already have stressed test to avoid memory crash).

Most of the time, it's due of plugins where memory leak happens. We will work on a way that you can spot a memory leak quickly before it becomes too hard to debug.

0
brandonaaskov
0
brandonaaskov
commented a year ago

@anish000kumar thank you very much! That --max-old-space-size=3072 flag was critical!

0
besnikh
0
besnikh
commented a year ago

@ALL
This is my finding regarding memory leak that I experienced in production.
We are using Nuxt & Vuetify latest version, and we after days of trying different things… We noticed that when a plugin is SSR Enabled, (or maybe some) the memory goes to roof, restart and again up.

This is screenshot from before:

fireshot capture 187 - kubernetes engine - tepazari-main_ - https___console cloud google com_k

This is screenshot last hour that we changed SSR to false to all plugins.
fireshot capture 188 - kubernetes engine - tepazari-main_ - https___console cloud google com_k

My eyes are not yet used with this straight line of memory :)

For my build we are dockerizing nuxt, at this time we are not using nginx but will add within a week, and with that using kubernetes cluster… until now we used high memory instances, but after this I guess that we will downgrade :)

here is how part of 'nuxt.conf.js' looks like

plugins: [
    {
      src: '~/plugins/vuetify.js',
      ssr: true
    },
    {
      src: '~/plugins/vee-validate.js',
      ssr: false
    },
    {
      src: '~/plugins/auth.js',
      ssr: false
    },
    {
      src: '~/plugins/anon.js',
      ssr: false
    },
    {
      src: '~/plugins/instant-search.js',
      ssr: false
    },
    {
      src: 'plugins/vue-carousel.js',
      ssr: false
    },
    {
      src: 'plugins/fire-auth',
      ssr: false
    }
  ],
vendor: [
      '~/plugins/vuetify.js'
    ],
    optimization: {
      splitChunks: {
        chunks: 'all',
        automaticNameDelimiter: '.',
        name: true,
        cacheGroups: {},
        minSize: 500000,
        maxSize: 500000
      }
    },
    maxChunkSize: 500000,
    extractCSS: true,
    filenames: {
      chunk: '[id].[chunkhash].js'
    },

I do hope this helps someone, since I was so desperate to find a way to get the memory in a straight line.
Maybe this is not a finding, but I do hope that some experts here will understand why better than I do.

That being said, if someone has suggestions on this case that would be awesome :)

Cheers,
Viva la Nuxt :P

0
manniL
5.8k
manniL
commented a year ago

@besnikh Thanks for your valuable insights! If you have time, could you make an analysis with the latest nuxt-edge build as well?

cc @clarkdo @Atinux @pi0

0
galvez
4.2k
galvez
commented a year ago

This thread has references to assorted issues relating to memory usage that may or not have been caused by something in Nuxt. Please everyone who's still having issues, open a new issue with a detailed reproduction branch.

0
ryanrca
5
ryanrca
commented a year ago

@All we found and fixed our memory leak, and it seems like it could be a common mistake on SSR sites, so I thought I would share.

We were instantiating a large common object on the server side but then deleting them on code that only ran on the client side.

In hindsight, It was an obvious memory leak, but may not seem so obvious to one who just entered the world of SSR.

To be more specific, we were creating an object event bus in created(). Just moving the event bus to beforeMount() completely resolved the issue.

1
kainbacher
0
kainbacher
commented a year ago

@anish000kumar thanks for sharing the script helped me a lot

0
Informations
Bug ReportOpen
#c7275 - Created a year ago