nuxt: FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
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.
<div align="right">This bug report is available on Nuxt.js community (#c1550)</div>About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 3
- Comments: 17 (3 by maintainers)
I am very disillusioned to admit that I still face this memory leak.
@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
VueComponentobjects 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 installexecutions, 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 withrunInNewContext: 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.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.
Just don’t use nuxt-link… use a helper component, which pushes to the $router object… so we can overcome this issue
Just like @AndruxaSazonov, I’m rendering a list of items with
nuxt-linkorrouter-linkand it is destroying my deployment. If list has more than 200 items, sometimes it returnsMaximum call stack size exceeded. With 1k items, probability to receive this error rises to 85%.