search

vercel / next.js

The React Framework
https://nextjs.org
MIT License
121.8k stars 26.05k forks source link

Next 9.5.1 out of memory after some hot reloads #15855

Closed macrozone closed 2 years ago

macrozone commented 3 years ago

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

Additional information

we are using a custom server with typescript

timneutkens commented 3 years ago

Please provide a reproduction so that we can investigate

macrozone commented 3 years ago

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

timneutkens commented 3 years ago

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.

macrozone commented 3 years ago

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

jjaybrown commented 3 years ago

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?

timneutkens commented 3 years ago

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.

chrysb commented 3 years ago

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".
macrozone commented 3 years ago

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
macrozone commented 3 years ago

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

timneutkens commented 3 years ago

@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

macrozone commented 3 years ago

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

daveteu commented 3 years ago

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::FullEvacuator, v8::internal::MarkCompactCollector>(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! project@1.0.0 dev: next dev -p 6000 npm ERR! Exit status 134 npm ERR! npm ERR! Failed at the project@1.0.0 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

project@1.0.0 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]

macrozone commented 3 years ago

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?

sbinlondon commented 3 years ago

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

(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.)

sbinlondon commented 3 years ago

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.

helsont commented 3 years ago

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".
lclc98 commented 3 years ago

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

stevez86 commented 3 years ago

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.

stevez86 commented 3 years ago

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

nandorojo commented 3 years ago

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 next@9.5.3. 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. 🤷🏼‍♂️

jackocnr commented 3 years ago

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 😞

bkniffler commented 3 years ago

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]
nodkz commented 3 years ago

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

matteing commented 3 years ago

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
mikestopcontinues commented 3 years ago

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
sharanya5 commented 3 years ago

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

naseef0 commented 3 years ago

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

bkniffler commented 3 years ago

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

jdfm commented 3 years ago

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:

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

negrudev commented 3 years ago

+1

carlosbaraza commented 3 years ago

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.

bkniffler commented 3 years ago

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!

sbinlondon commented 3 years ago

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.

nullhook commented 3 years ago

I've been getting this error too

<--- Last few GCs --->

[42091:0x10280e000] 55399024 ms: Mark-sweep 1342.9 (1430.5) -> 1342.8 (1415.5) MB, 283.0 / 0.0 ms  (average mu = 0.962, current mu = 0.000) last resort GC in old space requested
[42091:0x10280e000] 55399300 ms: Mark-sweep 1342.8 (1415.5) -> 1342.8 (1415.5) MB, 275.9 / 0.0 ms  (average mu = 0.929, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x313599078a1]
Security context: 0x38776269e6e9 <JSObject>
    1: byteLength(aka byteLength) [0x3877fbe79801] [buffer.js:~509] [pc=0x3135a35fee7](this=0x387710a026f1 <undefined>,string=0x3877679c7919 <Very long string[3510875]>,encoding=0x3877626be981 <String[4]: utf8>)
    2: arguments adaptor frame: 3->2
    3: from [0x3877b53203a9] [buffer.js:~199] [pc=0x3135cbac00f](this=0x3877fbe532b1 <JSFunction Buffer (sfi = 0...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x10003d035 node::Abort() [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 2: 0x10003d23f node::OnFatalError(char const*, char const*) [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 3: 0x1001b8e15 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 4: 0x100586d72 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 5: 0x100590274 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 6: 0x100562064 v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 7: 0x100693bd9 v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 8: 0x1001d6bad v8::String::Utf8Length() const [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
 9: 0x10005132b node::Buffer::(anonymous namespace)::ByteLengthUtf8(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/taher/.nvm/versions/node/v10.16.3/bin/node]
10: 0x313599078a1
mmmeff commented 3 years ago

We're also seeing the exact same out of memory crashes both in local development and in production.

Our cluster of Next.js containers keeps kicking over randomly under load with these out of memory errors.

Typescript/Styled-Components + custom server. No circular dependencies in our codebase.

I'm starting to consider adding something like nodemon to restart the process faster than our container orchestrator, but that's a bit of a hack, no?

sambecker commented 3 years ago

Same here.

This had virtually never happened to me until probably Next.js 10.0.3, possibly Next.js 10?

On an app I've been working on for almost a year?

App uses TypeScript, SASS, and Chrome Puppeteer. Other deps pretty typical?

<--- Last few GCs --->

[4347:0x10402c000]  4271127 ms: Mark-sweep 2076.1 (2101.5) -> 2075.4 (2084.3) MB, 283.6 / 0.0 ms  (average mu = 0.736, current mu = 0.000) last resort GC in old space requested
[4347:0x10402c000]  4271414 ms: Mark-sweep 2075.4 (2084.3) -> 2074.6 (2083.3) MB, 287.4 / 0.0 ms  (average mu = 0.572, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

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

Security context: 0x0d4493b80921 <JSObject>
    0: builtin exit frame: byteLength(aka byteLengthUtf8)(this=0x0d44a917a221 <Object map = 0xd44961e5b01>,0x0d4458adbf49 <Very long string[23199395]>,0x0d44a917a221 <Object map = 0xd44961e5b01>)

    1: fromStringFast(aka fromStringFast) [0xd44a9171cc9] [buffer.js:~419] [pc=0x3de063e0f79](this=0x0d4420a804b9 <undefined>,0x0d4458adbf49 <Very long string[23199395]>,0x0d44a917a221 <Object map = 0x...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x100bb159f node::Abort() (.cold.1) [/usr/local/bin/node]
 2: 0x10008979e node::FatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0x1000898df node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
 4: 0x10018bae5 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0x10018ba8f v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
miteshdhaduk commented 3 years ago

Facing the same issue in v10.16.0. Repeatedly stop service.

timneutkens commented 3 years ago

fwiw posting memory stacks is not going to solve this issue, we need full repositories including all customizations you've done in order to be able to even determine if this is caused by Next.js in your particular application or if it's caused by any of your other dependencies (e.g. you might have customized the webpack configuration). If you're not able to provide these please just use GitHub reactions on the initial issue (add a 👍) as the memory stacktrace is not helpful in tracking down what the issue is for your application.

Note that memory leaks can be introduced by your own code (e.g. if you render nested components in an infinite loop, if you create an object in the module scope and keep adding to it etc.) and by dependencies (e.g. React components from npm, libraries from npm etc.). Hence why I keep asking for full reproductions, as it's practically impossible to track these down for your particular case otherwise.

Also note that I want to solve this if it is related to Next.js, we just need more pointers from applications that experience this. We run a Next.js application with hundreds of pages and thousands of components with many developers and haven't experienced OOMs both during dev/build. The cases that we have investigated before mostly lead back to a certain dependency being imported that had a memory leak, this is also the reason why I brought up enterprise support (feel free to email enterprise@vercel.com) as a means of investigating this particular issue in your application, given I can't justify investigating days/weeks on an issue with no reproduction provided to date and that hasn't been reproducible to start investigating.

I hope you all understand and I'm looking forward to seeing a reproduction provided that can be investigated.

malimccalla commented 3 years ago

I'm also getting this issue and I have customised my directory structure to look something like the following... Thought i'd share incase this may be a common theme amongst occurrences.

- pages/
    index.tsx
    a.tsx
    b.tsx
    c.tsx
- views/
    index/
     index.tsx
    a/
     index.tsx
    b/
     index.tsx
    c/
     index.tsx

Each file under the pages directory exports the index from the corresponding views directory. For example, pages/a.tsx just contains.

export { default } from '../views/a';

I use this structure as I like to locate all related code under one directory (also see https://github.com/vercel/next.js/issues/4789#issuecomment-476758132). I'm not sure if this is even related to the OOM issue but felt it like it might be.

timneutkens commented 3 years ago

@thereactguys deleted your spam.

sambecker commented 3 years ago

FWIW haven't seen this happen since upgrading my system Node.js from 13 to 14. Will keep an eye on it.

SheaBelsky commented 3 years ago

@malimccalla I also have a similar setup to you, and have been experiencing the same Out of Memory errors as have been previously described. I'll see if removing these from my app mitigates the errors in any way. Thanks for the lead!

mmmeff commented 3 years ago

@sambecker Interesting - we honestly started seeing this after upgrading from Node 10 to 13. Upgrading to v14 is on the todo list and I'm really crossing my fingers that the issue just goes away when we do.

FWIW @timneutkens I appreciate your patience with this and the fact that you're not closings this outright. Getting bug reports like this must be frustrating, and I'm sure I'm not the only one when I say I'd love to share our source code with you but are legally unable to. I'm circling up with my team about potentially reaching out for enterprise support, but even that is less than ideal as the red tape to get that NDA signed will probably take us months.

My team is doing a lot of investigation into this right now and I'll be sure to share anything we find. The only smoking gun we've found is that a lot of the out of memory crash stacktraces point back to the etag header generation code that hashes the response before sending it. I don't think the actual issue is that code, but it seems to be indicative of Node poorly managing memory. If anything, this is quite possibly a Node bug.

skrivanos commented 3 years ago

@mmmeff Upgraded to Node 14 last week and we're still experiencing the same problem so I wouldn't count on that making a difference, unfortunately.

In our case it started happening when upgrading from Next 9.4.2 to 9.5.2 (without touching the Node version) so I'm not sure if it makes sense that it's a Node bug either.

macrozone commented 3 years ago

i did not do much investigation yet, it sill appears on development, but we also observed a memory leak in production. I therefore do not rule out a problem in our code base, but i am not sure if its is related to the dev-mode memory problem. 10.0.5 fixed one problem that might lead to memory leaks and we will find out soon if that fixes our production-memory-problem. keep you updated.

daveteu commented 3 years ago

My last comment here was in august 2020.

I haven't seen the OOM problem since I broke api files into smaller pieces AND stop/start dev whenever I switch branches.

mmmeff commented 3 years ago

@skrivanos Interesting, we also saw the issue pop up when we moved from 9.4 -> 10

timneutkens commented 3 years ago

@TheReactGuys please stop spamming. I've reported the account to GitHub.

skrivanos commented 3 years ago

@timneutkens Would you be interested in taking a look at our code base to solve this despite us lacking your Enterprise support package? Shoot me an e-mail if so.

ranisalt commented 3 years ago

I get this virtually every time after less than 10 reloads on Next 10