FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

[nilanjansiromani]

What version of Next.js are you using?

12.0.7

What version of Node.js are you using?

16.6.2

What browser are you using?

Chrome / safari

What operating system are you using?

Mac os

How are you deploying your application?

other

Describe the Bug

We have a monorepo with nx wherein we are using next for ssr We have been on next 11 and wanted to move to the next 12 with swc On doing so and making the neccessary changes, our app crashes with

We have tried adding more memory but we feel that the issue lies elsewhere

--- Last few GCs --->

[66122:0x7fe502d00000]   544670 ms: Mark-sweep (reduce) 4060.1 (4143.2) -> 4059.7 (4144.0) MB, 5936.8 / 0.1 ms  (average mu = 0.080, current mu = 0.001) allocation failure scavenge might not succeed
[66122:0x7fe502d00000]   550506 ms: Mark-sweep (reduce) 4060.8 (4144.0) -> 4060.4 (4144.7) MB, 5834.7 / 0.1 ms  (average mu = 0.042, current mu = 0.000) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0x108960ae5 node::Abort() (.cold.1) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 2: 0x1076563a9 node::Abort() [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 3: 0x10765651f node::OnFatalError(char const*, char const*) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 4: 0x1077d5137 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 5: 0x1077d50d3 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 6: 0x10798c0b5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 7: 0x10798aa79 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 8: 0x107996c9a v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
 9: 0x107996d21 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
10: 0x10796539c v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
11: 0x107d1680e v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
12: 0x10809fab9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/n0s00jx/.volta/tools/image/node/16.6.2/bin/node]
13: 0x10c684c2e 
14: 0x10c6847f5 

Expected Behavior

Should work

To Reproduce

• upgrade to next 12.0.7 / 12.0.4 and try running the dev server

[balazsorban44]

So you are saying this worked in next@11? Could you add an example/reproduction? :pray: How consistent is the error? Could you share more information on how did you encounter this?

[balazsorban44]

Seems to be a duplicate of #31962

[nilanjansiromani]

@balazsorban44 The error is persistent and consistent having said that, I had a couple of questions,

We were using the babel loader The procedure we followed to upgrade was

1. install next 12 (upgrade)
2. install @swc/core and swc-loader
3. Replace babel-loader with swc-loader
4. remove the existing babel config

now do we need to install @swc/core seperately, because i saw next install swc

[balazsorban44]

It depends on the babel plugins you were using. The most common ones are ported or being ported already. If you are missing anything, you could add feedback here about what is missing for you: https://github.com/vercel/next.js/discussions/30174

Apart from that, step 2 and 3 should not be necessary, and you don't have to install @swc/core either.

At this point, I think your problem is not originating from SWC though unless you can verify that using babel does not reproduce the issue.

If you have a persistent/consistent reproduction, that would be super helpful if you could share! :pray:

[nilanjansiromani]

thanks ... will revert on this in a couple of days

[federico-moretti]

I have the same problem:

• project with [email protected] works fine
• project with [email protected] crashes with the error above (tried [email protected] and the error remains)

In my case the project runs with docker-compose using the image node:16.13-alpine3.14, if the project is run on my machine (Intel Mac OS with Big Sur) it works fine, but within the container it crashes. Other infos that could help is that we use next-transpile-modules and treat/webpack-plugin in the next.config.js.

---

I resolved my issue adding the following to my next.config.js:

experimental: {
  esmExternals: false,
}

[killswitch-GUI]

Same here sadly. @federico-moretti that fix didnt work for me. I run a simular setup with it being node:16-slim

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb00d90 node::Abort() [node]
 2: 0xa1823b node::FatalError(char const*, char const*) [node]
 3: 0xcedbce v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xcedf47 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xea6105  [node]
 6: 0xea6be6  [node]
 7: 0xeb4b1e  [node]
 8: 0xeb5560 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0xeb84de v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0xe7990a v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
11: 0x11f303c v8::internal::Runtime_AllocateInOldGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
12: 0x15e7819  [node]
Aborted (core dumped)

[spirit-team]

We had that same issue while deploying in docker on RHEL 7.9 Next.JS v12.0.4 NodeJS: v16.13.0

This is part of our original package.json

"scripts": { "analyze": "cross-env ANALYZE=true next build", "dev": "next dev", "build": "set NODE_OPTIONS=--max-old-space-size=8192 && next build ", "start": "next start", },

We tried changing the max-old-space size to 12192 but it didnt help, we raised it some more to 16192 and it started working again. This is what it looks like now

"scripts": { "analyze": "cross-env ANALYZE=true next build", "dev": "next dev", "build": "set NODE_OPTIONS=--max-old-space-size=16192 && next build ", "start": "next start", },

[Tosinkoa]

Hello, I'm having this issue right now. And I've tried every possible solution I had came across but nothing works for me up till now, I still keep getting the error.

<--- Last few GCs --->

[5224:0000024358272890] 384386 ms: Mark-sweep (reduce) 1999.2 (2034.5) -> 1998.2 (2034.5) MB, 10434.1 / 0.0 ms (average mu = 0.114, current mu = 0.006) allocation failure scavenge might not succeed [5224:0000024358272890] 395047 ms: Mark-sweep (reduce) 1999.1 (2034.7) -> 1998.5 (2035.0) MB, 8674.0 / 0.0 ms (average mu = 0.149, current mu = 0.186) allocation failure GC in old space requested

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 1: 00007FF7228AF4CF v8::internal::CodeObjectRegistry::~CodeObjectRegistry+113967 2: 00007FF72283E4A6 SSL_get_quiet_shutdown+67398 3: 00007FF72283F35D node::OnFatalError+301 4: 00007FF72324A7EE v8::Isolate::ReportExternalAllocationLimitReached+94 5: 00007FF7232349FD v8::Isolate::Exit+653 6: 00007FF7230D658C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468 7: 00007FF7230D3A56 v8::internal::Heap::CollectGarbage+4294 8: 00007FF7230D13A0 v8::internal::Heap::AllocateExternalBackingStore+1904 9: 00007FF7230F4DF6 v8::internal::Factory::NewFillerObject+214 10: 00007FF722E2121A v8::internal::DateCache::Weekday+1658 11: 00007FF7232DCF71 v8::internal::SetupIsolateDelegate::SetupHeap+513649 12: 000002435A508AD4

[Tosinkoa]

Please anyone here knows the solution to the above problem, kindly help me out as I had been on this since four days ago

[Tosinkoa]

Please anyone here knows the solution to the above problem, kindly help me out as I had been on this since four days ago

[killswitch-GUI]

@Tosinkoa are you on a VM, local or container?

[Tosinkoa]

I'm still learning @killswitch-GUI can you please explain it?

[pmbanugo]

Thanks to @federico-moretti setting esmExternals: false solves it for me. Even with the default ESM setting in Next12, not all the ESM packages I use compile well. I still had to use the next-transpile-modules library to support them.

experimental: {
  esmExternals: false,
}

[Tosinkoa]

Thanks so much @pmbanugo When I couldn't solve the bug I had to use hard reset using git.

[floroz]

I just upgraded to 12.0.8 hoping this was solved but I am still having the FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory error.

Running:

• Next.js 12.0.8
• Node 16.13.0
• MacOS 12.1

[floroz]

I just upgraded to 12.0.8 hoping this was solved but I am still having the FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory error.

Running:

• Next.js 12.0.8
• Node 16.13.0
• MacOS 12.1

the application now compiles if adding the

experimental: {
        esmExternals: false,
    },

we also use external packages from our monorepo via next-transpile-module

[vishalrajole]

I am also observing same issue with node: 16.13.1 next: 11.1.3-canary.49

<--- Last few GCs --->

[15036:0x7fd756900000]  1746369 ms: Scavenge (reduce) 3951.9 (4091.4) -> 3951.5 (4091.6) MB, 3.0 / 0.0 ms  (average mu = 0.252, current mu = 0.272) allocation failure
[15036:0x7fd756900000]  1748893 ms: Mark-sweep (reduce) 4050.9 (4190.5) -> 4017.1 (4164.5) MB, 2083.6 / 0.1 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 2089 ms) (average mu = 0.388, current mu = 0.

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10fec1815 node::Abort() (.cold.1) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 2: 0x10ebc0aa9 node::Abort() [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 3: 0x10ebc0c1f node::OnFatalError(char const*, char const*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 4: 0x10ed41877 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 5: 0x10ed41813 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 6: 0x10eee2c65 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 7: 0x10eee15ec v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 8: 0x10eeedde0 v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
 9: 0x10eeede61 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
10: 0x10eeb4c00 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawOneByteInternalizedString(int, unsigned int) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
11: 0x10eeb4aa2 v8::internal::FactoryBase<v8::internal::Factory>::NewOneByteInternalizedString(v8::base::Vector<unsigned char const> const&, unsigned int) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
12: 0x10f18a82a v8::internal::Handle<v8::internal::String> v8::internal::StringTable::LookupKey<v8::internal::SequentialStringKey<unsigned char>, v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::SequentialStringKey<unsigned char>*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
13: 0x10ed76fb4 void v8::internal::AstValueFactory::Internalize<v8::internal::Isolate>(v8::internal::Isolate*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
14: 0x10f1adce8 v8::internal::Parser::DoParseProgram(v8::internal::Isolate*, v8::internal::ParseInfo*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
15: 0x10f1ad2de v8::internal::Parser::ParseProgram(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Script>, v8::internal::ParseInfo*, v8::internal::MaybeHandle<v8::internal::ScopeInfo>) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
16: 0x10f1d7555 v8::internal::parsing::ParseProgram(v8::internal::ParseInfo*, v8::internal::Handle<v8::internal::Script>, v8::internal::MaybeHandle<v8::internal::ScopeInfo>, v8::internal::Isolate*, v8::internal::parsing::ReportStatisticsMode) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
17: 0x10ede26ae v8::internal::(anonymous namespace)::CompileToplevel(v8::internal::ParseInfo*, v8::internal::Handle<v8::internal::Script>, v8::internal::MaybeHandle<v8::internal::ScopeInfo>, v8::internal::Isolate*, v8::internal::IsCompiledScope*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
18: 0x10ede5572 v8::internal::Compiler::GetWrappedFunction(v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::FixedArray>, v8::internal::Handle<v8::internal::Context>, v8::internal::ScriptDetails const&, v8::internal::ScriptData*, v8::ScriptCompiler::CompileOptions, v8::ScriptCompiler::NoCacheReason) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
19: 0x10ed4c70a v8::ScriptCompiler::CompileFunctionInContext(v8::Local<v8::Context>, v8::ScriptCompiler::Source*, unsigned long, v8::Local<v8::String>*, unsigned long, v8::Local<v8::Object>*, v8::ScriptCompiler::CompileOptions, v8::ScriptCompiler::NoCacheReason, v8::Local<v8::ScriptOrModule>*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
20: 0x10ebb2b0e node::contextify::ContextifyContext::CompileFunction(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
21: 0x10edaa239 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
22: 0x10eda9d06 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/vrajole/.nvm/versions/node/v16.13.1/bin/node]
23: 0x10eda947f v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
24: 0x10f61a399 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/vrajole/.nvm/versions/node/v16.13.1/bin/node]
25: 0x117fd6264
error Command failed with signal "SIGABRT".

[timneutkens]

Hey, so far we've spent over 10 hours trying to reproduce this and we can't find a problem with Next.js as-is. Please provide a reproduction so that we can continue investigating. A reproduction is a complete repository, sharing the heap allocation failed message unfortunately does not provide any useful data to further investigate.

[floroz]

Hey, so far we've spent over 10 hours trying to reproduce this and we can't find a problem with Next.js as-is. Please provide a reproduction so that we can continue investigating. A reproduction is a complete repository, sharing the heap allocation failed message unfortunately does not provide any useful data to further investigate.

have you troubleshot this both with esmExternal set to false and true ?

EDIT: I just tried again and got the same error, the application just doesn't compile without adding the

experimental: {
        esmExternals: false,
    },

I can't provide a repo to reproduce the error, but we use next-transpile-module and load around 139 internal packages from our monorepo.

I am running locally "next": "12.0.8", and

➜ ~ node -v
v16.13.0
➜ ~ yarn -v
1.22.17
➜ ~

Would be interesting to gather whether also previous reporter also make sure of next-transpile-modules

[pmbanugo]

@timneutkens Just like with @floroz We had to disable ESM for it to work. We also use next-transpile-modules because removing it causes the ESM errors for some packages that are native ESM. So our solution, for now, is to continue with the next-transpile-module and disable ESM experimental. Maybe they both don't play well together

[killswitch-GUI]

@timneutkens After a bit of time, we did get our build stable again. As the OP said they tried to add memory but they couldn't get it to build. Our fix was to give our Argo K8S pod 4GB in a relatively small project to build and run in dev mode. As dumb as it sounds this may all be due to the large increase of resources required for Next 12 vs 11! I think it really is an OOM issue, as ours was getting oomkilled. Not saying there isn't a memory leak here tho. After the bump we have been stable on NesxtJS 12 with all features enabled.

Edit: for clarity we previously ran our node at between 512-1GB

[timneutkens]

have you troubleshot this both with esmExternal set to false and true ?

With it enabled there is no memory leak, memory usage does not increase.

It's likely something in next-transpile-modules but we can't investigate that without a reproduction as it can be any combination of deps with that enabled.

As I've mentioned we'd be happy to investigate this further but it requires a full reproduction. If none is provided we can't spend more time on it at this point.

[pmbanugo]

@timneutkens After a bit of time, we did get our build stable again. As the OP said they tried to add memory but they couldn't get it to build. Our fix was to give our Argo K8S pod 4GB in a relatively small project to build and run in dev mode. As dumb as it sounds this may all be due to the large increase of resources required for Next 12 vs 11! I think it really is an OOM issue, as ours was getting oomkilled. Not saying there isn't a memory leak here tho. After the bump we have been stable on NesxtJS 12 with all features enabled.

Edit: for clarity we previously ran our node at between 512-1GB

Do you use next-transpile-modules?

[killswitch-GUI]

it works fine, but within the container it crashes.

We tackled that, the dev team was mounting in the nodejs modules when they used docker-compose or our K8S tilt dev environments. We had to exclude those from all of our docker builds + only mounting source code since NextJS 12 SWC (Is that true @programbo?) compiler in rust is architecture-dependent when built. Either way we never faced that on 11.

make sure you have node_modules/ in your .dockerignore or **node_modules/ in your .tiltignore.

@pmbanugo not at the moment.

[chrishornmem]

@timneutkens I have the same problem after upgrading from v11 to v12. Used memory on Mac goes up to 2.5GB before it bombs. Previously it was consuming < 1GB on v11. Happy to provide a full reproduction to you via private github. I'm using next-transpile-modules (required for amcharts4).

[balazsorban44]

Feel free to share the reproduction with Tim or me! :+1:

[chrishornmem]

@balazsorban44 added you and tim as collaborators - please check branch "crash"

[ddzieduch]

@chrishornmem I have also same issue in a project where I use amcharts v12.

I removed next-transpile-modules during update to Next.js 11.1.

I've added @balazsorban44 and @timneutkens as collaborators.

[chrishornmem]

@ddzieduch so your problem is still there on v12 after removing next-transpile-modules?