Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NEXT-841] FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory #32314

Closed
nilanjansiromani opened this issue Dec 9, 2021 · 191 comments
Assignees
Labels
linear: next Confirmed issue that is tracked by the Next.js team. Webpack Related to Webpack with Next.js.

Comments

@nilanjansiromani
Copy link

nilanjansiromani commented Dec 9, 2021

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

NEXT-841

@nilanjansiromani nilanjansiromani added the bug Issue was opened via the bug report template. label Dec 9, 2021
@balazsorban44
Copy link
Member

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

@balazsorban44
Copy link
Member

balazsorban44 commented Dec 9, 2021

Seems to be a duplicate of #31962

@balazsorban44 balazsorban44 added Webpack Related to Webpack with Next.js. please add a complete reproduction The issue lacks information for further investigation and removed bug Issue was opened via the bug report template. labels Dec 9, 2021
@nilanjansiromani
Copy link
Author

@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
Copy link
Member

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: #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! 🙏

@nilanjansiromani
Copy link
Author

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

@federico-moretti
Copy link

federico-moretti commented Dec 15, 2021

I have the same problem:

  • project with next@11.1.3 works fine
  • project with next@12.0.7 crashes with the error above (tried next@12.0.6-canary.6 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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

1 similar comment
@Tosinkoa
Copy link

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
Copy link

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

@Tosinkoa
Copy link

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

@pmbanugo
Copy link

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
Copy link

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

@floroz
Copy link

floroz commented Jan 12, 2022

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
Copy link

floroz commented Jan 12, 2022

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
Copy link

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
Copy link
Member

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
Copy link

floroz commented Jan 31, 2022

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
Copy link

@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
Copy link

killswitch-GUI commented Jan 31, 2022

@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
Copy link
Member

timneutkens commented Jan 31, 2022

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
Copy link

@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
Copy link

killswitch-GUI commented Feb 1, 2022

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
Copy link

chrishornmem commented Feb 7, 2022

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

@ValentinH
Copy link
Contributor

I started to face this issue recently and I managed to pinpoint it to the Edge runtime. See #51298

@alexstyl
Copy link

alexstyl commented Jun 17, 2023

Having the same issue. My app does not have a front end but holds thousands of files (3Kb) that are being served given an api function.

Tried both nextjs 12 and 13

@MuhammadMinhaj
Copy link

MuhammadMinhaj commented Jun 22, 2023

I got the same issue in Next.js 13.4.6. I didn't face such issues in Next.js 12!

@0xhipp0
Copy link

0xhipp0 commented Jun 28, 2023

I got the same issue in Next.js 13.4.6. I didn't face such issues in Next.js 12!

same, I downgraded back to the original version.

@MuhammadMinhaj
Copy link

MuhammadMinhaj commented Jun 28, 2023

I got the same issue in Next.js 13.4.6. I didn't face such issues in Next.js 12!

same, I downgraded back to the original version.

Now, I fixed the issue, It happens when you use top level imports cause it imports many unnecessary modules for a single page. As a result, Next.js needs to load thousands of modules, especially when using Mui icons.
The simple solution is to try using modularizeImports for Mui icons in your Next.js project. simply add the code below, and you will witness the actual magic of reducing unnecessary imports. In my case, it reduced the number of modules to around 20k.
codes:

modularizeImports: {
    '@mui/icons-material/?(((\\w*)?/?)*)': {
          transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}'
    }
}

simply paste it to the root level of the next.config.js file.

@origamih
Copy link

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,
}

This works for me. I'm running Next 12. Before this when do next dev memory spiked up to 6GB, now it goes down to 1.5GB

@roneymaia
Copy link

next@13.4.7

I know it sounds simple, but I solved this problem by removing the .next folder and running the build again. All methods mentioned here did not work. Only worked for my case was when I removed the folder.

@hongdeyuan
Copy link

I got the same issue in Next.js 13.4.6. I didn't face such issues in Next.js 12!

same, I downgraded back to the original version.

Now, I fixed the issue, It happens when you use top level imports cause it imports many unnecessary modules for a single page. As a result, Next.js needs to load thousands of modules, especially when using Mui icons. The simple solution is to try using modularizeImports for Mui icons in your Next.js project. simply add the code below, and you will witness the actual magic of reducing unnecessary imports. In my case, it reduced the number of modules to around 20k. codes:

modularizeImports: {
    '@mui/icons-material/?(((\\w*)?/?)*)': {
          transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}'
    }
}

simply paste it to the root level of the next.config.js file.

Personally, I think only the influence of @mui/icons-material was discharged, right?

@MuhammadMinhaj
Copy link

I got the same issue in Next.js 13.4.6. I didn't face such issues in Next.js 12!

same, I downgraded back to the original version.

Now, I fixed the issue, It happens when you use top level imports cause it imports many unnecessary modules for a single page. As a result, Next.js needs to load thousands of modules, especially when using Mui icons. The simple solution is to try using modularizeImports for Mui icons in your Next.js project. simply add the code below, and you will witness the actual magic of reducing unnecessary imports. In my case, it reduced the number of modules to around 20k. codes:

modularizeImports: {
    '@mui/icons-material/?(((\\w*)?/?)*)': {
          transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}'
    }
}

simply paste it to the root level of the next.config.js file.

Personally, I think only the influence of @mui/icons-material was discharged, right?

May be, I have encountered this issue with @mui/icons-material so far.

@hongdeyuan

This comment was marked as spam.

@xczdenis
Copy link

I have the same problem. None of the solutions helped me. I deleted the @mui/icons-material library, also deleted the .next folder and node_modules, then npm install again. The error has not gone away.

next 13.4.19, typescript 5.1.6

@NingXinHui
Copy link

Sorry about that, our stale bot accidentally closed it as it didn't have the right labels.

We're currently working on a refactor of how the server works that isolates running application code from Next.js itself. This will allow us to further narrow down memory issues

Still have the same problem now

@matbrgz
Copy link

matbrgz commented Sep 15, 2023

My error seems related to SWC, i'm trying to swcMinify: false, in my next.config.js.

▲  - info Creating an optimized production build...
▲  <--- Last few GCs --->
▲  
▲  [26909:0x715b4e0]   126869 ms: Mark-sweep 4020.0 (4146.1) -> 4020.0 (4139.6) MB, 649.1 / 0.0 ms  (average mu = 0.417, current mu = 0.028) allocation failure; scavenge might not succeed
▲  [26909:0x715b4e0]   127643 ms: Mark-sweep 4035.5 (4155.1) -> 4035.5 (4149.1) MB, 758.8 / 0.0 ms  (average mu = 0.255, current mu = 0.019) allocation failure; scavenge might not succeed
▲  <--- JS stacktrace --->
▲  FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
▲  1: 0xb83f50 node::Abort() [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  2: 0xa94834  [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  5: 0xf42265  [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  9: 0xf10760 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  10: 0xf081d4 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  11: 0xf0a568 v8::internal::FactoryBase<v8::internal::Factory>::NewRawTwoByteString(int, v8::internal::AllocationType) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  12: 0xf13a1c v8::internal::Factory::NewStringFromUtf8(v8::base::Vector<char const> const&, v8::internal::AllocationType) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  13: 0xd73873 v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  14: 0xb2cd8a napi_create_string_utf8 [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  15: 0x7f7a95e88a1e  [/home/cooper/dev/opendigital/start-frontend/node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node]
▲  16: 0x7f7a948eb4fc  [/home/cooper/dev/opendigital/start-frontend/node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node]
▲  17: 0x7f7a948e9960  [/home/cooper/dev/opendigital/start-frontend/node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node]
▲  18: 0x7f7a9187761e  [/home/cooper/dev/opendigital/start-frontend/node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node]
▲  19: 0xb4ab52 node::ThreadPoolWork::ScheduleWork()::{lambda(uv_work_s*, int)#2}::_FUN(uv_work_s*, int) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  20: 0x166224d  [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  21: 0x1666a36  [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  22: 0x1678f74  [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  23: 0x166739e uv_run [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  24: 0xac5a6d node::SpinEventLoop(node::Environment*) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  25: 0xbc8d14 node::NodeMainInstance::Run() [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  26: 0xb3ec18 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResult const*) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  27: 0xb4272f node::Start(int, char**) [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  28: 0x7f84c7fc4083 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
▲  29: 0xac1fee _start [/home/cooper/.nvm/versions/node/v18.17.1/bin/node]
▲  Error: Command "yarn run build" exited with 1

⚡️ The Vercel build (`yarn dlx vercel build`) command failed. For more details see the Vercel logs above.
⚡️ If you need help solving the issue, refer to the Vercel or Next.js documentation or their repositories.

Running the command cross-env NODE_OPTIONS=\"--max_old_space_size=4096 --trace-warnings\" npx @cloudflare/next-on-pages@1 suppress the error.

@itsmitul
Copy link

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

Getting this after upgrading to Next 13.5

@xRitsu
Copy link

xRitsu commented Sep 21, 2023

Same situation here. It happens randomly after the update to 13.5.

@wyozi
Copy link

wyozi commented Sep 22, 2023

Also started getting the error after 13.5 upgrade. Bumping heap size for build seemed to fix it

@RaulEscobarRivas

This comment was marked as spam.

@nexus6nexus6

This comment was marked as spam.

@matbrgz
Copy link

matbrgz commented Sep 22, 2023

Just to be clear and help this thread.

To suppress this error try export NODE_OPTIONS=\"--max_old_space_size=4096 --trace-warnings\" && <your-node-command> where is 4096 means how much RAM node can use, by default is 512MB, this must be in MB.

@LeonMueller-OneAndOnly
Copy link

LeonMueller-OneAndOnly commented Oct 6, 2023

Circular dependencies are oftentimes the culprit of really bad dev server performances. With the dev dependency dpdm we can analyse how many of those circular dependencies are present in our project:

scripts/detectCircularDependencies.ts

import { parseDependencyTree, parseCircular, prettyCircular } from "dpdm"

/**
 * Circular dependencies increase build times.
 * Especially the dev server suffers from this, the ram usage spikes heavily.
 *
 * Heuristic: The longer these circular dependencies are, the more they impact the performance.
 */

if (require.main === module) {
  void main()
}

async function main() {
  const circulars = await determineCirculars()

  circulars.sort((a, b) => b.length - a.length)

  console.log(prettyCircular(circulars)) // pretty-print to console

  console.log(
    `Circulars are sorted by length. Longest circular dependency spans ${
      circulars[0]?.length ?? "X"
    } modules`
  )
}

export async function determineCirculars(): Promise<string[][]> {
  return new Promise((resolve) => {
    void parseDependencyTree("./**/*.ts*", {
      // by transforming all files to javascript we avoid detecting circular type dependencies, whhich dont hurt at runtime
      transform: true,
      exclude: /node_modules\/*/,
    }).then((tree) => {
      resolve(parseCircular(tree))
    })
  })
}

package.json script

"detectCircularDependencies": "npx tsx scripts/detectCircularDependencies.ts"

Removing the 20 longest circular dependencies lead to a decrease from 14GB ram usage to 2GB ram usage in one project - since I have not analytically measured these values this should be taken with a grain of salt - still it shows how bad these are.

@KhalidRootDevs
Copy link

Having same issue on 13.5.4. Any idea how to solve this for the latest version?

@dbrxnds
Copy link

dbrxnds commented Oct 11, 2023

Hi @LeonMueller-OneAndOnly, thanks for the suggestion. We will be trying this out.

Do you mind sharing some insights about how bad your situation was? How many circular dependencies were there before? How many modules deep? etc.

@LeonMueller-OneAndOnly
Copy link

Hello @dbrxnds , i sadly no have any exact values. But i give a round about:

Present were at first 120 circular dependencies. Around 30 of them spanned more than 20 modules.

The good thing was that pretty much all were caused by one big bad barrell file.
Simply by fully specifying the exact module (instead of only providing the barrel file path) in like 5 places already eliminated around 20 of those really long circular dependencies.

Afterwards I were already able to start the dev server again. Since I had already written above script to easily find and track these bad circulars I continued to eliminate more circular dependencies, starting with the longest ones.

I decreased them to now around 30 circulars.
In the project there are still some circular dependencies present, but they only span 2 or 3 modules each - not ideal, but also not a dealbreaker.

The dev server is now very snappy again, a huge increase in developer experience!

Another benefit of this 2 hour excourse was that the average page bundle size decreased by 50%.

@Imran-S-heikh
Copy link

Imran-S-heikh commented Oct 17, 2023

I am facing the same issue and its kinda severe for me. Currently i am on nextjs 13.5.4. Its a nx monorepo and there have fairly good amount of apps . Here is the log:

<--- Last few GCs --->
[16619:0x67a00e0]  2846581 ms: Scavenge 4045.7 (4133.8) -> 4045.5 (4138.1) MB, 3.5 / 0.0 ms  (average mu = 0.623, current mu = 0.601) allocation failure 
[16619:0x67a00e0]  2846590 ms: Scavenge 4049.4 (4138.1) -> 4049.4 (4138.1) MB, 4.1 / 0.0 ms  (average mu = 0.623, current mu = 0.601) allocation failure 
[16619:0x67a00e0]  2846956 ms: Scavenge 4049.4 (4138.1) -> 4049.0 (4146.8) MB, 366.5 / 0.0 ms  (average mu = 0.623, current mu = 0.601) allocation failure 
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb090e0 node::Abort() [next-router-worker]
 2: 0xa1b70e  [next-router-worker]
 3: 0xce1a20 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [next-router-worker]
 4: 0xce1dc7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [next-router-worker]
 5: 0xe99435  [next-router-worker]
 6: 0xea90fd v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [next-router-worker]
 7: 0xeabdfe v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [next-router-worker]
 8: 0xe6d072 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [next-router-worker]
 9: 0xe65684 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [next-router-worker]
10: 0xe676e1 v8::internal::FactoryBase<v8::internal::Factory>::NewRawTwoByteString(int, v8::internal::AllocationType) [next-router-worker]
11: 0x1242e4c v8::internal::IncrementalStringBuilder::Extend() [next-router-worker]
12: 0xf91bed v8::internal::JsonStringifier::SerializeString(v8::internal::Handle<v8::internal::String>) [next-router-worker]
13: 0xf91219 v8::internal::JsonStringifier::SerializeString(v8::internal::Handle<v8::internal::String>) [next-router-worker]
14: 0xf96f8d v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<false>(v8::internal::Handle<v8::internal::Object>, bool, v8::internal::Handle<v8::internal::Object>) [next-router-worker]
15: 0xf98ddf v8::internal::JsonStringify(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [next-router-worker]
16: 0xd63c87 v8::internal::Builtin_JsonStringify(int, unsigned long*, v8::internal::Isolate*) [next-router-worker]
17: 0x15d9f39  [next-router-worker

@AshviniKumar90
Copy link

Circular dependencies are oftentimes the culprit of really bad dev server performances. With the dev dependency dpdm we can analyse how many of those circular dependencies are present in our project:

scripts/detectCircularDependencies.ts

import { parseDependencyTree, parseCircular, prettyCircular } from "dpdm"

/**
 * Circular dependencies increase build times.
 * Especially the dev server suffers from this, the ram usage spikes heavily.
 *
 * Heuristic: The longer these circular dependencies are, the more they impact the performance.
 */

if (require.main === module) {
  void main()
}

async function main() {
  const circulars = await determineCirculars()

  circulars.sort((a, b) => b.length - a.length)

  console.log(prettyCircular(circulars)) // pretty-print to console

  console.log(
    `Circulars are sorted by length. Longest circular dependency spans ${
      circulars[0]?.length ?? "X"
    } modules`
  )
}

export async function determineCirculars(): Promise<string[][]> {
  return new Promise((resolve) => {
    void parseDependencyTree("./**/*.ts*", {
      // by transforming all files to javascript we avoid detecting circular type dependencies, whhich dont hurt at runtime
      transform: true,
      exclude: /node_modules\/*/,
    }).then((tree) => {
      resolve(parseCircular(tree))
    })
  })
}

package.json script

"detectCircularDependencies": "npx tsx scripts/detectCircularDependencies.ts"

Removing the 20 longest circular dependencies lead to a decrease from 14GB ram usage to 2GB ram usage in one project - since I have not analytically measured these values this should be taken with a grain of salt - still it shows how bad these are.

Can we do same for angular application? as i am getting same error during deployment through Jenkins

@AshviniKumar90
Copy link

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb309a0 node::Abort() [ng build --prod --output-path=dist]
2: 0xa4219e node::FatalError(char const*, char const*) [ng build --prod --output-path=dist]
3: 0xd2389e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ng build --prod --output-path=dist]
4: 0xd23c17 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ng build --prod --output-path=dist]
5: 0xedd045 [ng build --prod --output-path=dist]
6: 0xeee48d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ng build --prod --output-path=dist]
7: 0xef11be v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ng build --prod --output-path=dist]
8: 0xeb2bda v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ng build --prod --output-path=dist]
9: 0x1233038 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ng build --prod --output-path=dist]
10: 0x16364b9 [ng build --prod --output-path=dist]
Aborted (core dumped)
error building image: error building stage: failed to execute command: waiting for process to exit: exit status 134
I am getting above error during our Angular application deployment through Jenkins

@timneutkens
Copy link
Member

Going to close this issue in favor of the more structured issue that explains what to do to help investigate the problem for your particular application: #54708

@vercel vercel locked and limited conversation to collaborators Oct 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
linear: next Confirmed issue that is tracked by the Next.js team. Webpack Related to Webpack with Next.js.
Projects
None yet
Development

No branches or pull requests