Nuxt.js: FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

[STnetwork]

Hi,

I use the nuxtent module, when I yarn generate I have this message :

<--- Last few GCs --->

[8503:0x2a784d0]   124609 ms: Mark-sweep 1402.9 (1492.6) -> 1402.9 (1488.1) MB, 1949.4 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1949 ms) last resort 
[8503:0x2a784d0]   126604 ms: Mark-sweep 1402.9 (1488.1) -> 1402.9 (1488.1) MB, 1993.6 / 0.0 ms  last resort 


<--- JS stacktrace --->

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

Security context: 0x3949dd29cef1 <JSObject>
    0: builtin exit frame: assign(this=0x3949dd29b919 <JSFunction Object (sfi = 0x3949dd29b869)>,0x1400f1560559 <Object map = 0x2313e04a25f9>,0x7863dde1671 <Object map = 0x3ecc755372b9>,0x19704383cf91 <Object map = 0x2313e0484829>)

    1: renderAttrs [/home/nginx/domains/stnetwork.fr/public/test/nuxtent/src/node_modules/vue-server-renderer/build.js:~335] [pc=0xe90ecc5a480](this=0xea43946c941 <J...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x13740dc [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewTransitionArray(int) [node]
 6: v8::internal::TransitionArray::Insert(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Map>, v8::internal::SimpleTransitionFlag) [node]
 7: v8::internal::Map::CopyReplaceDescriptors(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::DescriptorArray>, v8::internal::Handle<v8::internal::LayoutDescriptor>, v8::internal::TransitionFlag, v8::internal::MaybeHandle<v8::internal::Name>, char const*, v8::internal::SimpleTransitionFlag) [node]
 8: v8::internal::Map::CopyAddDescriptor(v8::internal::Handle<v8::internal::Map>, v8::internal::Descriptor*, v8::internal::TransitionFlag) [node]
 9: v8::internal::Map::CopyWithField(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::FieldType>, v8::internal::PropertyAttributes, v8::internal::PropertyConstness, v8::internal::Representation, v8::internal::TransitionFlag) [node]
10: v8::internal::Map::TransitionToDataProperty(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::PropertyConstness, v8::internal::Object::StoreFromKeyed) [node]
11: v8::internal::LookupIterator::PrepareTransitionToDataProperty(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::Object::StoreFromKeyed) [node]
12: v8::internal::Object::AddDataProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::Object::ShouldThrow, v8::internal::Object::StoreFromKeyed) [node]
13: v8::internal::Object::SetProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::LanguageMode, v8::internal::Object::StoreFromKeyed) [node]
14: v8::internal::JSReceiver::SetOrCopyDataProperties(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, v8::internal::ScopedVector<v8::internal::Handle<v8::internal::Object> > const*, bool) [node]
15: 0xc626b7 [node]
16: v8::internal::Builtin_ObjectAssign(int, v8::internal::Object**, v8::internal::Isolate*) [node]
17: 0xe90ec43c8dd
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

You can reproduce the issue with my repo

I opened an issue in the nuxtent-module, because I thought it was related to the module, but It's probably related to NuxtJS.

Thanks to help me.

_{This bug report is available on Nuxt.js community (#c1550)}

[uptownhr]

Just checking, is this happening in production or dev? Also is it happening during rebuild?

[STnetwork]

@uptownhr only when I yarn generate at the end of the process when he generates

[STnetwork]

Apparently I'm not alone :

https://github.com/nuxt/nuxt.js/issues/1695
https://github.com/nuxt/nuxt.js/issues/1601

[uptownhr]

Can you try running analyze? Would love to see how your bundles look like.

[STnetwork]

@uptownhr What do you mean exactly by running analyze ?

[choiRyan]

^ You can visually analyze your bundles by running build with argument -a or --analyze :) https://nuxtjs.org/api/configuration-build

[tillkolter]

@STnetwork You are definitely not alone. I also experienced problems with a memory leak this week.

Disclaimer: My staging environment has been running stable on v0.10.7 since 5 months and I still did not migrate to v1.0.0, because when I tried migrating during the alpha phase, there were too many side effects and now I feel too close to my clients production beta roll out to go through the migration pain. And due to the fact that people here were experiencing leaks with the latest v1.0.0-rc-11 and I didn't have issue with 0.10.7 until last week, I decided to stay on the deprecated version for my investigations.

Without exactly knowing what I was searching for (tbh: I did not even know what I was doing at all), I was trying to analyze heapdumps as suggested here: https://github.com/nuxt/nuxt.js/issues/805

No deeper knowledge was needed to observe that my dumps went incredibly large (~1,8G after 5 hours of uptime with almost no traffic) and were containing ridiculous amounts of VueComponent objects which were never released by the garbage collector and from my humble evaluation the leak seemed to be related to errors on the __VUE_SSR_CONTEXT__ as you can see in this screen shot:

It seemed that the memory leak started after I had dockerized my app. The fresh build pipeline introduced a couple of new module versions for dependencies which weren't issued before when I was manually updating the project with simple npm install executions, so I tried to pin my versions to the same versions that I could find in the old directory for the manual updates to see if the leak was disappearing. It turned out that my app was still crashing, sometimes after uptimes between 10 to 20 hours. The heap profiles also did not improve.

After 3 days of sweat and tears, I had my heureka moment today, when I realized, that there was a SSR rendering error (caused by testing for this.$route.name.startsWith('something')) on my dev server command line, which I did not pay attention to, because everything looked fine in the client and expecting the root cause for the leak to be deeper inside the framework made me completely blind-eyed for cleaning in front of my own house. I fixed the null pointer error (don't know if that is the correct term in the Javascript lingua) and now the garbage collector seems to do his job as expected. At least the current heap comparison shows an healthy amount of object deletions now.

Maybe my story is unique and incredibly stupid, but I wanted to share it, because I found a couple of similar threads on this topic here. Just in case somebody becomes blind-eyed like I did, I recommend to make sure that the dev server output is not showing any weird errors. Even if your front end works fine and you ignore the output to focus on the bigger problem, there might be a good chance, that you introduced the problem yourself.

@pi0 @Atinux @alexchopin Although my problem was home-made and could be fixed, there might still be a general problem when errors in the space of the __VUE_SSR_CONTEXT__ happen. I am aware that you reuse the context with runInNewContext: false, so I guess the amount of allocated memory is drastically reduced by that alone, but judging from the current complaints there might still be issues (like in my case) where this alone does not help avoiding the sort of memory leak I produced. Does my assumption make any sense? I hope my investigations could still give any lead, considering that I am still running on v0.10.7. People are still experiencing errors on the latest release candidate, so I guess there is still room for improvements? If you are interested I could also share the heapdumps of my malicious version.

[pi0]

@tillkolter Your investigation and report is more than enough 👍 So seems this problem is going to happen when some errors occur on server side. Would you please share (partial) .vue file which was causing this leak?

[tillkolter]

My app contains an AudioPlayer component with a v-show directive on the root element to hide the player on certain routes. My problem was, that I didn't think of the home page case.

I think this is everything you would need to reproduce it in a minimal example:

default.vue

<div id="app">
   <audio-player></audio-player>
</div>
...

AudioPlayer.vue

<template>
   <div v-show="showPlayer">
   ...
   </div>
</template>
...
<script>
....
export default {
  name: 'AudioPlayer'
  computed: {
    showPlayer () {
      let name = this.$route.name
      return !['checkout', 'cart'].includes(name) && !name.startsWith('account')
  }
}
...
</script>

https://github.com/tillkolter/nuxt-oye-records/blob/master/components/audio/AudioPlayer.vue

The project also has a Dockerfile https://github.com/tillkolter/nuxt-oye-records

[AndruxaSazonov]

Confirm. My question 1750 is of the same nature, and leak caused not by the asyncData: after removing components (which use arrays from asyncData) from template (and hence, rendering) - memory usage decreases after some time to (a little bit more value, but) very near the initial.

Also noticed huge positive impact on event loop perfomance (since no context coping maybe). Despite of above, I have no renderer warnings or errors at all (except of missing images in browser, but it doesn't matter, because I'm profiling with apache bench).

And one more thing - all of my components inclusions are surrounded by divs of other containers and don't use computed data.

[AndruxaSazonov]

Colleagues, sorry for crossposting #1750 (the details are there), but I think it is important to notice, that context copies made with vue-router via nuxt-link.

I have a heavy page with many-many nuxt-links (catalog), > 200 links. When I apparently changed them to simple anchors, SSR instance memory footprint decreased after load test to initial values in meaningful time.

[tillkolter]

I am very disillusioned to admit that I still face this memory leak.

[levibostian]

To help debug the issue, I have 3 commits for my site you can pull and run which are causing this exception on my machine:

My latest occurrence: https://github.com/levibostian/levibostian.com/tree/0ff08e49c014054b42b189aa3541f14252233de1

Also, from a couple months ago (still having issue): https://github.com/nuxt-community/nuxtent-module/issues/35 I include more details with this commit: https://github.com/levibostian/levibostian.com/tree/c4d17e971ee7f79098d1b5c899f7be0e6cf1375e

[varna]

Just like @AndruxaSazonov, I'm rendering a list of items with nuxt-link or router-link and it is destroying my deployment. If list has more than 200 items, sometimes it returns Maximum call stack size exceeded. With 1k items, probability to receive this error rises to 85%.

[Atinux]

#1728

[daspete]

Just don't use nuxt-link... use a helper component, which pushes to the $router object... so we can overcome this issue

[lock[bot]]

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.