Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

anish000kumar opened this issue Jun 22, 2018 — with CMTY · 20 comments


Copy link

@anish000kumar anish000kumar commented Jun 22, 2018 — with CMTY



Reproduction link

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.

This bug report is available on Nuxt community (#c7275)
@cmty cmty bot added the bug-report label Jun 22, 2018
Copy link

@aldarund aldarund commented Jun 23, 2018

node version? happens every time?

Copy link

@XavierLeTohic XavierLeTohic commented Jun 25, 2018

Same thing happening for me, sometimes.

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

Copy link

@anish000kumar anish000kumar commented Jun 28, 2018

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

Copy link

@anish000kumar anish000kumar commented Jun 29, 2018

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

// Sessions to create req.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') = !isProd
const nuxt = new Nuxt(config)
// No build in production
const promise = (isProd ? Promise.resolve() : new Builder(nuxt).build())
promise.then(() => {
  console.log('Server is listening on http://localhost:3000')  // eslint-disable-line no-console
.catch((error) => {
  console.error(error)  // eslint-disable-line no-console

And in package.json add this:

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

Then use npm run serve

Copy link

@appinteractive appinteractive commented Jul 8, 2018

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

Copy link

@ryanrca ryanrca commented Jul 11, 2018

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

Copy link

@RDeluxe RDeluxe commented Jul 18, 2018

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

Copy link

@aldarund aldarund commented Jul 20, 2018

Happened to me only once

Copy link

@appinteractive appinteractive commented Jul 20, 2018

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


Copy link

@jameshhood jameshhood commented Jul 30, 2018

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.

Copy link

@seanwash seanwash commented Jul 30, 2018

@jameshhood I've been using 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.

@Atinux Atinux added this to To do in Bugs 🐞 Aug 7, 2018
Copy link

@bok04 bok04 commented Aug 9, 2018

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

Copy link

@Atinux Atinux commented Aug 9, 2018

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.

Copy link

@brandonaaskov brandonaaskov commented Aug 16, 2018

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

Copy link

@besnikh besnikh commented Aug 30, 2018

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: [
    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 :)

Viva la Nuxt :P

Copy link

@manniL manniL commented Sep 2, 2018

@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

Copy link

@galvez galvez commented Sep 3, 2018

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.

@galvez galvez closed this Sep 3, 2018
Bugs 🐞 automation moved this from Open to Fixed Sep 3, 2018
Copy link

@ryanrca ryanrca commented Sep 4, 2018

@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.

Copy link

@kainbacher kainbacher commented Oct 25, 2018

@anish000kumar thanks for sharing the script helped me a lot

Copy link

@lock lock bot commented Nov 24, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Nov 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
No open projects
Bugs 🐞
Linked pull requests

Successfully merging a pull request may close this issue.

None yet