Next.js: Next 9.5.1 out of memory after some hot reloads

Created on 4 Aug 2020  ·  33Comments  ·  Source: vercel/next.js

Bug report

Describe the bug

Since updating to 9.5.x (from 9.4.x), i get an out of memory error after 10 something hot reloads:

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

it did rarely happen in 9.4.1, but it happens very consistantly in 9.5.x

To Reproduce

thats probably tricky. it happens on big projects and might be related to some bug in the hot reload / rebuild. Maybe it happens when there are some import circles?

Expected behavior

nextjs should not go out-of-memory

System information

  • OS:macOS
  • Browser: chrome
  • Version of Next.js: 9.5.1
  • Version of Node.js: 12.13.1

Additional information

we are using a custom server with typescript

please add a complete reproduction

Most helpful comment

Please provide a reproduction so that we can investigate

this is extremly hard to do, but i am 100% sure others have the same issue. Do you hav any idea how this could happen? Its a new problem and happens very consistantly.

maybe circular dependencies? I investigate now in that

All 33 comments

Please provide a reproduction so that we can investigate

Please provide a reproduction so that we can investigate

this is extremly hard to do, but i am 100% sure others have the same issue. Do you hav any idea how this could happen? Its a new problem and happens very consistantly.

maybe circular dependencies? I investigate now in that

but i am 100% sure others have the same issue

Haven't heard anything from our development teams or others, vercel.com is a Next.js app with 250 unique Next.js pages so we would have definitely have run into it if it was as trivial as you're making it to be.

Do you hav any idea how this could happen?

Issues with memory are practically impossible to investigate without having the application so now I can't give you pointers on where to look. You'll have to run tooling to track down where memory is allocated (e.g. the Node.js debugger profiler).

If it makes it any easier to share the application we can also investigate it under (paid) enterprise support if that makes the company you work for share the application, which will likely save your development team significant amounts of time.

but i am 100% sure others have the same issue

Haven't heard anything from our development teams or others, vercel.com is a Next.js app with 250 unique Next.js pages so we would have definitely have run into it if it was as trivial as you're making it to be.

Do you hav any idea how this could happen?

Issues with memory are practically impossible to investigate without having the application so now I can't give you pointers on where to look. You'll have to run tooling to track down where memory is allocated (e.g. the Node.js debugger profiler).

If it makes it any easier to share the application we can also investigate it under (paid) enterprise support if that makes the company you work for share the application, which will likely save your development team significant amounts of time.

will think abou that, thank you

We are also seeing the same problem, including in production, I can't provide a reproduction due to sensitivity, but I can provide a next.config and plugins/env if that would be acceptable?

I can't provide a reproduction due to sensitivity, but I can provide a next.config and plugins/env if that would be acceptable?

Unlikely we'll be able to track it down based on just a next.config.js.

As said before if the only concern is that the code is sensitive we can look at enterprise support which would include a NDA.

I can confirm this is happening to us as well after upgrading to 9.5.1. Crashes after hot reloading a number of times.

<--- Last few GCs --->
ti[60368:0x108008000] 11172836 ms: Mark-sweep 2051.4 (2060.3) -> 2049.2 (2060.3) MB, 166.8 / 0.1 ms  (+ 0.0 ms in 9 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 197 ms) (average mu = 0.194, current mu = 0.151) allocatio[60368:0x108008000] 11173027 ms: Mark-sweep 2049.4 (2060.3) -> 2049.3 (2060.3) MB, 187.1 / 0.0 ms  (+ 0.0 ms in 1 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 191 ms) (average mu = 0.114, current mu = 0.020) allocatio

<--- JS stacktrace --->

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

Security context: 0x262dea1408d1 <JSObject>
    0: builtin exit frame: utf8Slice(this=0x262d2d605ab9 <Uint8Array map = 0x262d167e4479>,828330,0,0x262d2d605ab9 <Uint8Array map = 0x262d167e4479>)

    1: slice [0x262dc6d1aaf1] [buffer.js:603] [bytecode=0x262d6562bd59 offset=7](this=0x262dc6d1a021 <Object map = 0x262d167e4f69>,0x262d2d605ab9 <Uint8Array map = 0x262d167e4479>,0,828330)
    2: toString [0x262d45cdd099] [buffer.js:~771] [pc=0x2...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x1010248bd node::Abort() (.cold.1) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 2: 0x100084c4d node::FatalError(char const*, char const*) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 3: 0x100084d8e node::OnFatalError(char const*, char const*) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 4: 0x100186477 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 5: 0x100186417 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 6: 0x1003141c5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 7: 0x100315a3a v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 8: 0x10031246c v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
 9: 0x10031026e v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
10: 0x10031c169 v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
11: 0x10031c1c1 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
12: 0x1002ec04b v8::internal::Factory::NewRawTwoByteString(int, v8::internal::AllocationType) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
13: 0x1002ebfb6 v8::internal::Factory::NewStringFromUtf8(v8::internal::Vector<char const> const&, v8::internal::AllocationType) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
14: 0x1001a8e82 v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
15: 0x100114da1 node::StringBytes::Encode(v8::Isolate*, char const*, unsigned long, node::encoding, v8::Local<v8::Value>*) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
16: 0x10006c63a void node::Buffer::(anonymous namespace)::StringSlice<(node::encoding)1>(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
17: 0x1001f40e8 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
18: 0x1001f36a9 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
19: 0x1001f2dd2 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
20: 0x10097d6b9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
21: 0x100902f64 Builtins_InterpreterEntryTrampoline [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
22: 0x24fc3b2a0e4b 
23: 0x1008fc5bc Builtins_ArgumentsAdaptorTrampoline [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
24: 0x100902f64 Builtins_InterpreterEntryTrampoline [/Users/chrysbader/.nvm/versions/node/v12.16.2/bin/node]
25: 0x24fc3b0cd39b 
error Command failed with signal "SIGABRT".

I tried to debug it with profiler,

i just see that the app takes roughly 1.6 - 1.9 GB just after the first page compilation. Maybe its just too big for nextjs to handle.

I noticed that webpack seems to cache a lot of sources in memory:

Bildschirmfoto 2020-08-07 um 10 25 10

i tried now setting NODE_OPTIONS='--max_old_space_size=4096' and it seems to be better at first glance

@macrozone I'd really like to have a look at the application myself as it's pretty much impossible to judge if that's a problem based on that one screenshot. E.g. the compilation object is only holding 200mb of memory

@timneutkens ok, can you send me a message? (my work email should be under my account)

I have been experiencing memory leak since 9.5.2 (I updated yesterday). I was working on the /api/ files yesterday and this morning when it will randomly crash during hot reloads.

Since today afternoon, I was working on material-ui and some api

After I kept making changes to makeStyles, and changing the classes back and forth (because I'm trying to get the layout right), then it will crash after quite a few hot reload compiling.

Below, shows the number of hot reloads (in between the 2 crashes, I was working on material-ui's makeStyles and adding/removing classes to different component) and compiles while I'm playing with makeStyles and material-ui's Accordion component.

I'm not sure whether the logs below help, but I have to say the crashes are all pretty random, so far crashed about 10-15 times in the span of 24 hours, sometimes when working on /api/ sometimes while working on material-ui.

wait - compiling...

<--- Last few GCs --->

[3511:0x4ac6840] 1722755 ms: Scavenge 454.2 (462.5) -> 451.2 (463.0) MB, 3.2 / 0.1 ms (average mu = 0.984, current mu = 0.618) allocation failure
[3511:0x4ac6840] 1722796 ms: Scavenge 455.0 (463.0) -> 451.5 (463.0) MB, 1.8 / 0.0 ms (average mu = 0.984, current mu = 0.618) allocation failure
[3511:0x4ac6840] 1723246 ms: Mark-sweep 474.1 (484.8) -> 461.6 (482.1) MB, 400.5 / 0.1 ms (average mu = 0.987, current mu = 0.989) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
1: 0xa3ac30 node::Abort() [node]
2: 0x98a45d node::FatalError(char const, char const) [node]
3: 0xbae25e v8::Utils::ReportOOMFailure(v8::internal::Isolate, char const, bool) [node]
4: 0xbae5d7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, bool) [node]
5: 0xd56125 [node]
6: 0xd8178e v8::internal::EvacuateNewSpaceVisitor::Visit(v8::internal::HeapObject, int) [node]
7: 0xd8da96 v8::internal::FullEvacuator::RawEvacuatePage(v8::internal::MemoryChunk, long) [node]
8: 0xd7b4ef v8::internal::Evacuator::EvacuatePage(v8::internal::MemoryChunk) [node]
9: 0xd7b768 v8::internal::PageEvacuationTask::RunInParallel(v8::internal::ItemParallelJob::Task::Runner) [node]
10: 0xd70dc9 v8::internal::ItemParallelJob::Run() [node]
11: 0xd8fbfe void v8::internal::MarkCompactCollectorBase::CreateAndExecuteEvacuationTasks(v8::internal::MarkCompactCollector
, v8::internal::ItemParallelJob, v8::internal::MigrationObserver, long) [node]
12: 0xd90494 v8::internal::MarkCompactCollector::EvacuatePagesInParallel() [node]
13: 0xd90665 v8::internal::MarkCompactCollector::Evacuate() [node]
14: 0xda1857 v8::internal::MarkCompactCollector::CollectGarbage() [node]
15: 0xd63dd9 v8::internal::Heap::MarkCompact() [node]
16: 0xd64c0b v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
17: 0xd65684 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
18: 0xd680fc v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
19: 0xd2f3aa v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
20: 0xd29254 v8::internal::FactoryBase::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [node]
21: 0xd2b5a1 v8::internal::FactoryBase::NewRawTwoByteString(int, v8::internal::AllocationType) [node]
22: 0xf89565 v8::internal::String::SlowFlatten(v8::internal::Isolate, v8::internal::Handle, v8::internal::AllocationType) [node]
23: 0xbc1369 v8::String::Utf8Length(v8::Isolate
) const [node]
24: 0xa13067 [node]
25: 0xc19bab [node]
26: 0xc1b156 [node]
27: 0xc1b7d6 v8::internal::Builtin_HandleApiCall(int, unsigned long, v8::internal::Isolate) [node]
28: 0x13f5159 [node]
Aborted (core dumped)
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! [email protected] dev: next dev -p 6000
npm ERR! Exit status 134
npm ERR!
npm ERR! Failed at the [email protected] dev script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /home/ubuntu/.npm/_logs/2020-08-15T17_43_39_015Z-debug.log
ubuntu@ip-172-31-35-196:~/project2$ npm run dev

[email protected] dev /home/ubuntu/project
next dev -p 6000

info - Loaded env from /home/ubuntu/project2/.env.local
ready - started server on http://localhost:6000
event - compiled successfully
event - build page: /next/dist/pages/_error
wait - compiling...
event - compiled successfully
event - build page: /dashboard/customer/[pid]
wait - compiling...
event - compiled successfully
event - build page: /api/dashboard/[[...path]]
wait - compiling...
event - compiled successfully
wait - compiling...
event - compiled successfully
wait - compiling...
event - compiled successfully
event - build page: /api/dashboard/[[...path]]
wait - compiling...
event - compiled successfully
wait - compiling...
event - compiled successfully
wait - compiling...
event - compiled successfully
wait - compiling...
error - ./src/components/Dashboard/Activity.js:25:25
Syntax error: Identifier directly after number

23 | accordionExpandedNoExtraMargin: {
24 |

25 | minHeight: 48px !important'
| ^
26 | },
27 | expandNothing: {
28 |
wait - compiling...
event - compiled successfully
event - build page: /dashboard
wait - compiling...
event - compiled successfully
wait - compiling...
event - compiled successfully
wait - compiling...
event - compiled successfully
wait - compiling...
<--- Last few GCs --->

[3573:0x503a840] 357009 ms: Scavenge 454.7 (462.2) -> 452.0 (462.9) MB, 3.1 / 0.0 ms (average mu = 0.950, current mu = 0.668) allocation failure
[3573:0x503a840] 357025 ms: Scavenge 456.3 (464.6) -> 454.2 (465.1) MB, 2.7 / 0.0 ms (average mu = 0.950, current mu = 0.668) allocation failure
[3573:0x503a840] 357472 ms: Mark-sweep 476.2 (486.9) -> 456.4 (481.3) MB, 382.0 / 0.1 ms (average mu = 0.990, current mu = 0.994) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
1: 0xa3ac30 node::Abort() [node]
2: 0x98a45d node::FatalError(char const, char const) [node]
3: 0xbae25e v8::Utils::ReportOOMFailure(v8::internal::Isolate, char const, bool) [node]
4: 0xbae5d7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, bool) [node]

We use styled-components (latest version 5.1.1), which similarly to material-ui creates global styes that will be injected into the head. Maybe the improvements of hot reloading interfers with that?

I've been having the same issue for about 1-2 weeks as well. After starting up my local dev environment, I work for a bit and then end up having to restart due to a crash. I also get these report.*.json files put into my root directory. This has happened most days.

System information

  • OS: MacOS Catalina 10.15.6
  • Browser: Firefox 79
  • Version of Next.js: 9.5.1 (upgraded 15 days ago) & continuing in 9.5.2 (upgraded 8 days ago)
  • Version of Node.js: 12.16.1 (with NVM)

(I can provide the full Node-generated report JSON if needed).

A coworker and I also noticed we were getting this error too:

TypeError: Cannot destructure property 'components' of 'object null' as it is null.
    at DevServer.renderToHTMLWithComponents (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:60:246)
    at DevServer.renderErrorToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:101:332)
    at async DevServer.renderErrorToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/server/next-dev-server.js:30:1204)
    at async DevServer.renderError (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:100:1173)
TypeError: Cannot destructure property 'components' of 'object null' as it is null.
    at DevServer.renderToHTMLWithComponents (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:60:246)
    at DevServer.renderErrorToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:101:332)
    at async DevServer.renderErrorToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/server/next-dev-server.js:30:1204)
    at async DevServer.renderToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:100:974)
    at async DevServer.renderToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/server/next-dev-server.js:30:578)
    at async DevServer.render (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:55:236)
TypeError: Cannot destructure property 'components' of 'object null' as it is null.
    at DevServer.renderToHTMLWithComponents (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:60:246)
    at DevServer.renderErrorToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:101:332)
    at async DevServer.renderErrorToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/server/next-dev-server.js:30:1204)
    at async DevServer.renderToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:100:974)
    at async DevServer.renderToHTML (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/server/next-dev-server.js:30:578)
    at async DevServer.render (/Users/katebeard/coding/opencollective/opencollective-frontend/node_modules/next/dist/next-server/server/next-server.js:55:236)

Please provide a reproduction so that we can investigate

When you say this do you mean a link to a PR with a live app on Vercel? We might be able to provide since Open Collective is open source and all our repos are open. (Edited to add: here's the PR I've been working on where I experienced the latest crashes, you can pull the code from our repo and see the Vercel app link in the PR.)

Quick follow up: these are some messages I've been getting in my terminal warning of a memory leak.

Screenshot 2020-08-19 at 18 45 48
Screenshot 2020-08-19 at 18 46 11

It points specifically to this file in our frontend repo, which has an unnamed default export. It's one of the oldest files in our repo and definitely wasn't causing issues before. Perhaps there's been a change in the way Next.js handles these default unnamed exports that would cause the memory leak? This for example seems to be a new addition released within the last few weeks that was flagging that particular error, and warning of a memory leak.

I played around making some changes to a component I've been working on this week while the crashes have been most notable, and was able to trigger one again just now.

Here's the output from my terminal:

wait  - compiling...
event - compiled successfully
event - build page: /editCollective
wait  - compiling...
event - compiled successfully
event - build page: /collective-page
wait  - compiling...
event - compiled successfully
wait  - compiling...

<--- Last few GCs --->

[15737:0x102925000]  5850165 ms: Mark-sweep 2052.8 (2068.5) -> 2051.9 (2068.5) MB, 419.6 / 0.2 ms  (average mu = 0.783, current mu = 0.000) last resort GC in old space requested
[15737:0x102925000]  5850866 ms: Mark-sweep 2051.9 (2068.5) -> 2051.5 (2067.8) MB, 701.2 / 0.1 ms  (average mu = 0.602, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 0x2bc03c1408d1 <JSObject>
    0: builtin exit frame: byteLength(aka byteLengthUtf8)(this=0x2bc07bf6fd89 <Object map = 0x2bc0a06a4ba9>,0x2bc09252c761 <Very long string[34224816]>,0x2bc07bf6fd89 <Object map = 0x2bc0a06a4ba9>)

    1: fromString(aka fromString) [0x2bc07bf67d79] [buffer.js:~424] [pc=0x2784c0fe4651](this=0x2bc0bd7c04b1 <undefined>,0x2bc09252c761 <Very long string[34224816]>,0x2bc0eba27999 <String[#4]: utf8>)
...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x100080c68 node::Abort() [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 2: 0x100080dec node::errors::TryCatchScope::~TryCatchScope() [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 3: 0x100185167 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 4: 0x100185103 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 5: 0x10030b2f5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 6: 0x1003130ed v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 7: 0x1002e273c v8::internal::Factory::NewRawTwoByteString(int, v8::internal::AllocationType) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 8: 0x100533c81 v8::internal::String::SlowFlatten(v8::internal::Isolate*, v8::internal::Handle<v8::internal::ConsString>, v8::internal::AllocationType) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
 9: 0x1001a42ad v8::String::Utf8Length(v8::Isolate*) const [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
10: 0x100064354 node::Buffer::(anonymous namespace)::ByteLengthUtf8(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
11: 0x1001f08f0 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
12: 0x1001efecf v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
13: 0x1001ef5d0 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
14: 0x100950a19 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/katebeard/.nvm/versions/node/v12.16.1/bin/node]
15: 0x2784c0fe4651 
zsh: abort      npm run dev
~/coding/opencollective/opencollective-frontend  (git)-[master]- -> 

Node had been using around ~1.9 GB for a while and I'm not sure if it helped trigger it or if it was coincidence but when I switched branches and made a few more changes that seemed to push it over the edge of the available 2GB of memory.

I've noticed this issue happen 4 -5 times in the past month. It has happened when switching branches, but it also just happened when I updated my JSX to have an inline style. I tend to run yarn dev for multiple days on end.

wait  - compiling...
event - compiled successfully
wait  - compiling...
event - compiled successfully
wait  - compiling...

<--- Last few GCs --->
nce start of marking 305 ms) (average mu = 0.778, current mu = 0.186) allocatio[20536:0x104091000] 57744365 ms: Mark-sweep 2083.8 (2090.9) -> 2083.8 (2090.9) MB, 346.4 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 394 ms) (average mu = 0.651, current mu = 0.121) last reso[20536:0x104091000] 57744720 ms: Mark-sweep 2083.8 (2090.9) -> 2083.7 (2090.9) MB, 354.6 / 0.0 ms  (average mu = 0.483, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x1007538f9]
    1: StubFrame [pc: 0x1007964e0]
Security context: 0x3eb61e880921 <JSObject>
    2: replace [0x3eb61e88cdd1](this=0x3eb6896a1cc9 <Very long string[29761]>,0x3eb61dbdef61 <JSRegExp <String[#10]: \n(?=.|\s)>>,0x3eb6c6363451 <String[9]\: \n/******/>)
    3: source [0x3eb61dbdfaf1] [/Users/helson/Development/polyops/ui/node_modules/webpack-sources/lib/PrefixSource.js:43] [bytecode=0x3eb6c634d381 offset=60]...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x100080a4c node::Abort() [/usr/local/Cellar/node/13.13.0_2/bin/node]
 2: 0x100080bc2 node::OnFatalError(char const*, char const*) [/usr/local/Cellar/node/13.13.0_2/bin/node]
 3: 0x100180be5 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node/13.13.0_2/bin/node]
 4: 0x100180b8f v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node/13.13.0_2/bin/node]
 5: 0x10029a5c3 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/Cellar/node/13.13.0_2/bin/node]
 6: 0x10029facc v8::internal::Heap::SetUp() [/usr/local/Cellar/node/13.13.0_2/bin/node]
 7: 0x10027ca79 v8::internal::Factory::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [/usr/local/Cellar/node/13.13.0_2/bin/node]
 8: 0x10027ee6c v8::internal::Factory::NewRawOneByteString(int, v8::internal::AllocationType) [/usr/local/Cellar/node/13.13.0_2/bin/node]
 9: 0x100441a9f v8::internal::String::SlowFlatten(v8::internal::Isolate*, v8::internal::Handle<v8::internal::ConsString>, v8::internal::AllocationType) [/usr/local/Cellar/node/13.13.0_2/bin/node]
10: 0x1004bb6d9 v8::internal::RegExpImpl::IrregexpExec(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::RegExpMatchInfo>) [/usr/local/Cellar/node/13.13.0_2/bin/node]
11: 0x100504307 v8::internal::Runtime_RegExpExec(int, unsigned long*, v8::internal::Isolate*) [/usr/local/Cellar/node/13.13.0_2/bin/node]
12: 0x1007538f9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/usr/local/Cellar/node/13.13.0_2/bin/node]
13: 0x1007964e0 Builtins_RegExpReplace [/usr/local/Cellar/node/13.13.0_2/bin/node]
14: 0x100740ae2 Builtins_StringPrototypeReplace [/usr/local/Cellar/node/13.13.0_2/bin/node]
error Command failed with signal "SIGABRT".

I seem to get this crash after I change some CSS in the same file as tailwind imports, I am also using typescript. I am currently trying to create a test repo. Repo based on blog-starter-typescript but slightly modified https://github.com/lclc98/NextOOM

I've been getting this issue consistently after 1-2 hot reloads after upgrading to 9.5. It makes the dev experience slow (constantly restarting) and barely usable. The OOM occurred on 9.4 but much less frequently (once an hour) Has anyone been able to improve / resolve this issue?

@timneutkens it looks like we have a few repros, I can also throw mine into the mix but would need to be under an NDA.

FYI anyone having issues I was able to greatly reduce this by removing the headers function in my next config.

I've been getting this error with 9.5 as my site has grown in size. It happens whenever I fast refresh and have been in dev mode for over 15 minutes. I could share my repo privately if it's helpful @timneutkens

Update, fixed

I refactored my entire app to make sure that there was absolutely no circular importing. I also changed my package.json script to run with this:

{
  "scripts": {
    "start": "NODE_OPTIONS=--max_old_space_size=8192 next"
  }
}

Now it's working just fine. Not sure what did it exactly, but I have a feeling it was a circular imports. So I recommend making sure you don't have circular imports in your app.

For context, I'm on [email protected]. I'm also using Expo + Next.js, and I upgraded to Expo SDK39 from 38 and react-native-web 0.14. Unsure if that had anything to do with it or not. 🤷🏼‍♂️

FWIW I was getting this error using an old version of Node (v10.15.3), and I stopped getting it after I upgraded to v12.18.4.

Edit: nope, it just stopped for a while, then came back 😞

Also happening to me since a few months now. I'm always on the latest version of nextjs and I'm using libraries such as elastic-ui, less, graphql (via urql), typescript. Its happening quite frequently, I'd say every 30-60 minutes of working, and always after the wait - compiling... step, so I guess its got something to do with hot reloading / fast refreshing.

<--- Last few GCs --->

[82128:0x102a81000]  5231616 ms: Mark-sweep 2091.9 (2100.2) -> 2091.6 (2100.2) MB, 260.0 / 0.1 ms  (average mu = 0.584, current mu = 0.000) last resort GC in old space requested
[82128:0x102a81000]  5231884 ms: Mark-sweep 2091.6 (2100.2) -> 2090.3 (2100.2) MB, 267.7 / 0.0 ms  (average mu = 0.393, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x1009031ed]
Security context: 0x114e2ee408d1 <JSObject>
    1: fromStringFast(aka fromStringFast) [0x114ed3830861] [buffer.js:~419] [pc=0x10518a017a5d](this=0x114e903404b1 <undefined>,0x114e8f155aa1 <Very long string[32212516]>,0x114ed38387d9 <Object map = 0x114ef48e5059>)
    2: fromString(aka fromString) [0x114ed38308a1] [buffer.js:452] [bytecode=0x114ebda2bd59 offset=117](this=0x114e903404b1 <undefined>,0x114e8f1...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x1010285f9 node::Abort() (.cold.1) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 2: 0x10008634d node::FatalError(char const*, char const*) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 3: 0x10008648e node::OnFatalError(char const*, char const*) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 4: 0x100187c07 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 5: 0x100187ba7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 6: 0x100315955 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 7: 0x10031d9fc v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 8: 0x1002ed7db v8::internal::Factory::NewRawTwoByteString(int, v8::internal::AllocationType) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
 9: 0x1005561e2 v8::internal::String::SlowFlatten(v8::internal::Isolate*, v8::internal::Handle<v8::internal::ConsString>, v8::internal::AllocationType) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
10: 0x1001a5a6d v8::String::Utf8Length(v8::Isolate*) const [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
11: 0x10006976e node::Buffer::(anonymous namespace)::ByteLengthUtf8(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]
12: 0x1009031ed Builtins_CallApiCallback [/Users/bkniffler/.nvm/versions/node/v12.16.3/bin/node]

I'm also using less. I suppose that problem somewhere with webpack & less-loader.

Having this issue, increasing in severity + frequency lately.

<--- Last few GCs --->

[6948:0x102888000] 12101179 ms: Mark-sweep 2097.6 (2110.7) -> 2097.5 (2110.5) MB, 310.4 / 0.0 ms  (average mu = 0.954, current mu = 0.001) last resort GC in old space requested
[6948:0x102888000] 12101498 ms: Mark-sweep 2097.5 (2110.5) -> 2096.2 (2110.0) MB, 318.6 / 0.0 ms  (average mu = 0.908, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 0x0f6e59c408a1 <JSObject>
    0: builtin exit frame: byteLength(aka byteLengthUtf8)(this=0x0f6e2b3342a1 <Object map = 0xf6e19765b91>,0x0f6eabbb3759 <Very long string[9587152]>,0x0f6e2b3342a1 <Object map = 0xf6e19765b91>)

    1: fromStringFast(aka fromStringFast) [0xf6e2b32bba1] [buffer.js:398] [bytecode=0xf6eab716b71 offset=7](this=0x0f6ea06c04a9 <undefined>,0x0f6eabbb3759 <Very long string[9587152]>,0x0f6e2b3342a1 <Obj...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x10007f231 node::Abort() [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 2: 0x10007f3b5 node::OnFatalError(char const*, char const*) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 3: 0x100176887 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 4: 0x100176823 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 5: 0x1002fa9d5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 6: 0x100302788 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 7: 0x1002d15c3 v8::internal::Factory::NewRawTwoByteString(int, v8::internal::AllocationType) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 8: 0x100517c71 v8::internal::String::SlowFlatten(v8::internal::Isolate*, v8::internal::Handle<v8::internal::ConsString>, v8::internal::AllocationType) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
 9: 0x10019559d v8::String::Utf8Length(v8::Isolate*) const [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
10: 0x100062306 node::Buffer::(anonymous namespace)::ByteLengthUtf8(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
11: 0x1001e1ba0 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
12: 0x1001e117f v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
13: 0x1001e0880 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
14: 0x1009312f9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/sergio/.nvm/versions/node/v12.14.1/bin/node]
[1]    6946 abort      npm run dev

I'm getting this too, at least once or twice per full coding day. I rarely reset my dev server unless this happens.

<--- Last few GCs --->

[4189:0x108008000] 57528940 ms: Mark-sweep 2043.9 (2057.4) -> 2043.6 (2057.4) MB, 296.9 / 0.1 ms  (average mu = 0.847, current mu = 0.000) last resort GC in old space requested
[4189:0x108008000] 57529232 ms: Mark-sweep 2043.6 (2057.4) -> 2042.4 (2057.4) MB, 292.6 / 0.1 ms  (average mu = 0.739, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x10096318d]
Security context: 0x0d0130dc08d1 <JSObject>
    1: from [0xd01da971429] [buffer.js:~304] [pc=0x1ebb7473ac17](this=0x0d01a72cd061 <JSFunction Buffer (sfi = 0xd01da967bf9)>,0x0d01b079fac1 <Very long string[18934961]>,0x0d01da969bf9 <String[#4]: utf8>,0x0d01bddc04b1 <undefined>)
    2: writeOut(aka writeOut) [0xd01f8106219] [/Users/msc/Code/@sitearcade/hub/node_modules/webpack/lib/Compiler.js:457] [bytecode...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x1011d1cc5 node::Abort() (.cold.1) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 2: 0x10009f919 node::Abort() [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 3: 0x10009fa7f node::OnFatalError(char const*, char const*) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 4: 0x1001e38b7 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 5: 0x1001e3857 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 6: 0x10036b9e5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 7: 0x100373a8c v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 8: 0x1003435fb v8::internal::Factory::NewRawTwoByteString(int, v8::internal::AllocationType) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
 9: 0x1005ab2d2 v8::internal::String::SlowFlatten(v8::internal::Isolate*, v8::internal::Handle<v8::internal::ConsString>, v8::internal::AllocationType) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
10: 0x10020171d v8::String::Utf8Length(v8::Isolate*) const [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
11: 0x10007e69b node::Buffer::(anonymous namespace)::ByteLengthUtf8(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
12: 0x10096318d Builtins_CallApiCallback [/Users/msc/.nvm/versions/node/v12.18.4/bin/node]
sh: line 1:  4188 Abort trap: 6

I'm facing the same issue if I don't keep restarting the server now and then, and after updating to the latest version there seems to be an issue with hot reloading too. Sometimes I have to refresh the site manually.

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

I have the same issue... i updated next version to v9.5.0. after that i got memory heap issue.

Tried this also.. export NODE_OPTIONS="--max_old_space_size=6096.
Getting issue after 2 or 3 Route changing.

Screenshot 2020-10-27 at 1 32 17 PM

Still happening with latest v10, in case anyone was hoping it could've been solved by chance.

I can also confirm that this is happening. It seems like it may be related to page navigation somehow, as, when trying to come up with reproducible steps, we noticed that if we stayed on the same page and tried a series of change+save loops to get the hot reloading to fire quickly, it wouldn't crash. But, if we tried navigating through our app for a bit, and then doing a few change+save loops we would quickly get to a point where it crashed.

A few properties of the codebase I'm working on:

  • We use styled-components (currently at v5.1.0) and we have a babel.config.js file that we use so we can properly SSR the styles (mentioning this because of what was reported https://github.com/vercel/next.js/issues/7929#issuecomment-707222434)
  • We use Typescript in the codebase (currently at v4.0.3)
  • We are currently on NextJS v9.5.5 (upgraded recently from v9.3.6)
  • We have a number of circular dependencies in our codebase
  • There are a lot of components in our codebase, ranging from ones we created ourselves to ones we import via component libraries that were created in house

As far as I know, no one on our team had this issue on NextJS v9.3.6.

+1

Not sure this would help anyone, but in our case, we just realized that we had a plugin in next.config.js called webpack-stats-plugin which was causing most of the memory leaks. The way we debugged that was starting nodemon with --inspect, taking a memory heap snapshot, and then we found most of the biggest strings were related to some Webpack stats.

Thanks for the hint @carlosbaraza. I'm not using the stats-plugin, but a bunch of others (next-optimized-images, @next/bundle-analyzer though disabled mostly, copy-webpack-plugin). I'll debug/profile too, and maybe everyone here should try.

There is a really good tutorial on profiling nodejs + nextjs here:
https://alberic.trancart.net/2020/05/how-fixed-first-memory-leak-nextjs-nodejs/

Just make sure to change your dev script to something like scripts: { "dev": "NODE_OPTIONS='--inspect' next -p 4000" } and share your findings!

Just a small update:

Used node-oom-heapdump to grab a heap snapshot of our app when it crashed.

Screenshot 2020-11-13 at 12 18 22

It seems to call out one of Webpack's dependencies, watchpack (and its DirectoryWatcher.js), which makes sense to me because my crashes happen the most when I'm in dev mode, switching between branches that have a large number of changed files between them.

I have sent the heap snapshot to the Next.js team so hopefully it will help them look into this. I think I'm potentially going to open an issue on the Watchpack repo as well.

Was this page helpful?
0 / 5 - 0 ratings