search

vercel / next.js

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

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

Closed nilanjansiromani closed 7 months ago

nilanjansiromani commented 2 years ago

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

NEXT-841

balazsorban44 commented 2 years ago

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 commented 2 years ago

Seems to be a duplicate of #31962

nilanjansiromani commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

federico-moretti commented 2 years ago

I have the same problem:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Tosinkoa commented 2 years ago

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

pmbanugo commented 2 years ago

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 commented 2 years ago

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

floroz commented 2 years ago

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:

floroz commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

chrishornmem commented 2 years ago

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

ddzieduch commented 2 years ago

@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 commented 2 years ago

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

chrishornmem commented 2 years ago

Following worked for me in next.config.js

const withTM = require("next-transpile-modules")([
  "@amcharts/amcharts4",
]);

module.exports = withTM({
  experimental: {
    esmExternals: false,  // required to stop the FATAL heap crash
  },
});

Used memory drops to ~1GB from >2.5GB

ddzieduch commented 2 years ago

@balazsorban44 any update

should I go back to the pre-11.1 settings?

Tosinkoa commented 2 years ago

For me, when this stopped the project I was working on for more than a week, and all the solution I found was not helping, I have to do a hard revert using git. I believe a mistake somebody don't know about was made by me.

isNan909 commented 2 years ago

Suddenly I also faced this issue. I tried changing and reinstalling node and downgrading node to v16 and also Next v11.0 but the issue still exists.

I worked into this project for nearly 4-5 hours, lights went off and I was back to this project but server was running for about an hour of inactivity. And this error happened.

But this worked fine in a blank fresh project. I can share repository if I need. This runs with SWC.

Please let me know if this issue resolves.

Running version:

Node 17.5.0 Next 12.1.0 npm 8.4.1 swc 1.2.2

lokhmakov commented 2 years ago

It's just on new ubuntu ec2 with 1Gb memory + 4Gb swap.

On MAC works fine without any magic.

balazsorban44 commented 2 years ago

@nilanjansiromani regarding https://github.com/vercel/next.js/issues/32314#issuecomment-991833909 were you able to create a reproduction for this?

Anyone else, please note that the best you can do to help with this issue is to provide a reproduction repository that has been simplified to be as minimal as possible but the issue still consistently reproduces. Remove everything that is not necessary for the reproduction, so we can exclude as many variables as possible. :+1:

Refer to Tim's comment: https://github.com/vercel/next.js/issues/32314#issuecomment-1025549719

balazsorban44 commented 2 years ago

@chrishornmem we looked into your reproduction, and could not see an immediate problem, but we have suspected for a long time now that next-transpile-modules plays a part in the problem. We will try to look more into that. We also determined that most likely you can get rid of your .babelrc config which would result in a faster compilation overall.

@ddzieduch we looked into your reproduction as well, and it does not use Next.js 12. Could you upgrade and see how that works out? We don't backport bugfixes (only security-related) so even if there was a bug, the recommended fix would be to upgrade first.

boyluan commented 2 years ago

hey @lokhmakov can you elaborate a little, please. what do you mean run export NODE_OPTIONS=--max_old_space_size=4096 "before start helps." ?

I want to make sure I fully understand what you mean. thanks!

lokhmakov commented 2 years ago

@solaxds https://github.com/vercel/next.js/issues/32314#issuecomment-995223414

LukasBombach commented 2 years ago

We are also having JavaScript heap out of memory crashes with a similar setup:

The error is consistent and persistant. All of our team members have their node processes crash at some point.

I am trying hard to create a reproducible example, but I have no luck yet.

But I noticed a curious thing in our actual project: Some of the webpack cache files (*.pack) tend to be curiously large with about 200MB, they have 100.000+ LOC with lines having about 10.000 chars

I am not sure if that is an expected behavior but I thought I might report this to add to the intel

LukasBombach commented 2 years ago

Oh and the long lines are related to emotion

_c = Color70608d;
var colorf83e71 = false ? {
  name: "1h3hwmz",
  styles: "display:inline-block;width:1em;text-indent:-9999em;background:#f83e71"
} : {
  name: "fea5ay-colorf83e71",
  styles: "display:inline-block;width:1em;text-indent:-9999em;background:#f83e71;label:colorf83e71;",
  map: "/*# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIi9Vc2Vycy9sdWtlL1Byb2plY3RzL25leHQtanMtaGVhcC1vdXQtb2YtbWVtb3J5LXJlcHJvZHVjaWJsZS1leGFtcGxlL3VpLWxpYnJhcnkvc3JjL2dlbmVyYXRlZF9kb250X3RvdWNoL0ZpbGU3OS50c3giXSwibmFtZXMiOltdLCJtYXBwaW5ncyI6IkFBT3VCIiwiZmlsZSI6Ii9Vc2Vycy9sdWtlL1Byb2plY3RzL25leHQtanMtaGVhcC1vdXQtb2YtbWVtb3J5LXJlcHJvZHVjaWJsZS1leGFtcGxlL3VpLWxpYnJhcnkvc3JjL2dlbmVyYXRlZF9kb250X3RvdWNoL0ZpbGU3OS50c3giLCJzb3VyY2VzQ29udGVudCI6WyJcbiAgICAvLyBpbXBvcnQgc3R5bGVkIGZyb20gXCJAZW1vdGlvbi9zdHlsZWRcIjtcbiAgICBpbXBvcnQgeyBjc3MgfSBmcm9tICdAZW1vdGlvbi9yZWFjdCdcbiAgICBpbXBvcnQgdHlwZSB7IFZGQywgRkMgfSBmcm9tIFwicmVhY3RcIjtcblxuICAgIGNvbnN0IGNvbG9yNzA2MDhkID0gY3NzYGRpc3BsYXk6IGlubGluZS1ibG9jazsgd2lkdGg6IDFlbTsgdGV4dC1pbmRlbnQ6IC05OTk5ZW07IGJhY2tncm91bmQ6ICM3MDYwOGQ7YDtcbiAgICAgICAgICBjb25zdCBDb2xvcjcwNjA4ZDogRkMgPSAoeyBjaGlsZHJlbiB9KSA9PiA8c3BhbiBjc3M9e2NvbG9yNzA2MDhkfT57Y2hpbGRyZW59PC9zcGFuPlxuY29uc3QgY29sb3JmODNlNzEgPSBjc3NgZGlzcGxheTogaW5saW5lLWJsb2NrOyB3aWR0aDogMWVtOyB0ZXh0LWluZGVudDogLTk5OTllbTsgYmFja2dyb3VuZDogI2Y4M2U3MTtgO1xuICAgICAgICAgIGNvbnN0IENvbG9yZjgzZTcxOiBGQyA9ICh7IGNoaWxkcmVuIH0pID0+IDxzcGFuIGNzcz17Y29sb3JmODNlNzF9PntjaGlsZHJlbn08L3NwYW4+XG5jb25zdCBjb2xvcjc4MTA3NiA9IGNzc2BkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IHdpZHRoOiAxZW07IHRleHQtaW5kZW50OiAtOTk5OWVtOyBiYWNrZ3JvdW5kOiAjNzgxMDc2O2A7XG4gICAgICAgICAgY29uc3QgQ29sb3I3ODEwNzY6IEZDID0gKHsgY2hpbGRyZW4gfSkgPT4gPHNwYW4gY3NzPXtjb2xvcjc4MTA3Nn0+e2NoaWxkcmVufTwvc3Bhbj5cbmNvbnN0IGNvbG9yYzQzZjk0ID0gY3NzYGRpc3BsYXk6IGlubGluZS1ibG9jazsgd2lkdGg6IDFlbTsgdGV4dC1pbmRlbnQ6IC05OTk5ZW07IGJhY2tncm91bmQ6ICNjNDNmOTQ7YDtcbiAgICAgICAgICBjb25zdCBDb2xvcmM0M2Y5NDogRkMgPSAoeyBjaGlsZHJlbiB9KSA9PiA8c3BhbiBjc3M9e2NvbG9yYzQzZjk0fT57Y2hpbGRyZW59PC9zcGFuPlxuY29uc3QgY29sb3I4NGRiYmEgPSBjc3NgZGlzcGxheTogaW5saW5lLWJsb2NrOyB3aWR0aDogMWVtOyB0ZXh0LWluZGVudDogLTk5OTllbTsgYmFja2dyb3VuZDogIzg0ZGJiYTtgO1xuICAgICAgICAgIGNvbnN0IENvbG9yODRkYmJhOiBGQyA9ICh7IGNoaWxkcmVuIH0pID0+IDxzcGFuIGNzcz17Y29sb3I4NGRiYmF9PntjaGlsZHJlbn08L3NwYW4+XG5jb25zdCBjb2xvcjkxNGMyNCA9IGNzc2BkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IHdpZHRoOiAxZW07IHRleHQtaW5kZW50OiAtOTk5OWVtOyBiYWNrZ3JvdW5kOiAjOTE0YzI0O2A7XG4gICAgICAgICAgY29uc3QgQ29sb3I5MTRjMjQ6IEZDID0gKHsgY2hpbGRyZW4gfSkgPT4gPHNwYW4gY3NzPXtjb2xvcjkxNGMyNH0+e2NoaWxkcmVufTwvc3Bhbj5cbmNvbnN0IGNvbG9yYjEwMzg1ID0gY3NzYGRpc3BsYXk6IGlubGluZS1ibG9jazsgd2lkdGg6IDFlbTsgdGV4dC1pbmRlbnQ6IC05OTk5ZW07IGJhY2tncm91bmQ6ICNiMTAzODU7YDtcbiAgICAgICAgICBjb25zdCBDb2xvcmIxMDM4NTogRkMgPSAoeyBjaGlsZHJlbiB9KSA9PiA8c3BhbiBjc3M9e2NvbG9yYjEwMzg1fT57Y2hpbGRyZW59PC9zcGFuPlxuY29uc3QgY29sb3JmMmFjMWIgPSBjc3NgZGlzcGxheTogaW5saW5lLWJsb2NrOyB3aWR0aDogMWVtOyB0ZXh0LWluZGVudDogLTk5OTllbTsgYmFja2dyb3VuZDogI2YyYWMxYjtgO1xuICAgICAgICAgIGNvbnN0IENvbG9yZjJhYzFiOiBGQyA9ICh7IGNoaWxkcmVuIH0pID0+IDxzcGFuIGNzcz17Y29sb3JmMmFjMWJ9PntjaGlsZHJlbn08L3NwYW4+XG5jb25zdCBjb2xvcjA5M2ZmOSA9IGNzc2BkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IHdpZHRoOiAxZW07IHRleHQtaW5kZW50OiAtOTk5OWVtOyBiYWNrZ3JvdW5kOiAjMDkzZmY5O2A7XG4gICAgICAgICAgY29uc3QgQ29sb3IwOTNmZjk6IEZDID0gKHsgY2hpbGRyZW4gfSkgPT4gPHNwYW4gY3NzPXtjb2xvcjA5M2ZmOX0+e2NoaWxkcmVufTwvc3Bhbj5cbmNvbnN0IGNvbG9yZjNlYjY2ID0gY3NzYGRpc3BsYXk6IGlubGluZS1ibG9jazsgd2lkdGg6IDFlbTsgdGV4dC1pbmRlbnQ6IC05OTk5ZW07IGJhY2tncm91bmQ6ICNmM2ViNjY7YDtcbiAgICAgICAgICBjb25zdCBDb2xvcmYzZWI2NjogRkMgPSAoeyBjaGlsZHJlbiB9KSA9PiA8c3BhbiBjc3M9e2NvbG9yZjNlYjY2fT57Y2hpbGRyZW59PC9zcGFuPlxuY29uc3QgY29sb3JlYzBmYzEgPSBjc3NgZGlzcGxheTogaW5saW5lLWJsb2NrOyB3aWR0aDogMWVtOyB0ZXh0LWluZGVudDogLTk5OTllbTsgYmFja2dyb3VuZDogI2VjMGZjMTtgO1xuICAgICAgICAgIGNvbnN0IENvbG9yZWMwZmMxOiBGQyA9ICh7IGNoaWxkcmVuIH0pID0+IDxzcGFuIGNzcz17Y29sb3JlYzBmYzF9PntjaGlsZHJlbn08L3NwYW4+XG5jb25zdCBjb2xvcjY2OThjOSA9IGNzc2BkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IHdpZHRoOiAxZW07IHRleHQtaW5kZW50OiAtOTk5OWVtOyBiYWNrZ3JvdW5kOiAjNjY5OGM5O2A7XG4gICAgICAgICAgY29uc3QgQ29sb3I2Njk4Yzk6IEZDID0gKHsgY2hpbGRyZW4gfSkgPT4gPHNwYW4gY3NzPXtjb2xvcjY2OThjOX0+e2NoaWxkcmVufTwvc3Bhbj5cbmNvbnN0IGNvbG9yMTFjMzM0ID0gY3NzYGRpc3BsYXk6IGlubGluZS1ibG9jazsgd2lkdGg6IDFlbTsgdGV4dC1pbmRlbnQ6IC05OTk5ZW07IGJhY2tncm91bmQ6ICMxMWMzMzQ7YDtcbiAgICAgICAgICBjb25zdCBDb2xvcjExYzMzNDogRkMgPSAoeyBjaGlsZHJlbiB9KSA9PiA8c3BhbiBjc3M9e2NvbG9yMTFjMzM0fT57Y2hpbGRyZW59PC9zcGFuPlxuY29uc3QgY29sb3IzM2QwYzQgPSBjc3NgZGlzcGxheTogaW5saW5lLWJsb2NrOyB3aWR0aDogMWVtOyB0ZXh0LWluZGVudDogLTk5OTllbTsgYmFja2dyb3VuZDogIzMzZDBjNDtgO1xuICAgICAgICAgIGNvbnN0IENvbG9yMzNkMGM0OiBGQyA9ICh7IGNoaWxkcmVuIH0pID0+IDxzcGFuIGNzcz17Y29sb3IzM2QwYzR9PntjaGlsZHJlbn08L3NwYW4+XG5jb25zdCBjb2xvcjkwNmQ5OSA9IGNzc2BkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IHdpZHRoOiAxZW07IHRleHQtaW5kZW50OiAtOTk5OWVtOyBiYWNrZ3JvdW5kOiAjOTA2ZDk5O2A7XG4gICAgICAgICAgY29uc3QgQ29sb3I5MDZkOTk6IEZDID0gKHsgY2hpbGRyZW4gfSkgPT4gPHNwYW4gY3NzPXtjb2xvcjkwNmQ5OX0+e2NoaWxkcmVufTwvc3Bhbj5cbmNvbnN0IGNvbG9yNjNlZjAxID0gY3NzYGRpc3BsYXk6IGlubGluZS1ibG9jazsgd2lkdGg6IDFlbTsgdGV4dC1pbmRlbnQ6IC05OTk5ZW07IGJhY2tncm91bmQ6ICM2M2VmMDE7YDtcbiAgICAgICAgICBjb25zdCBDb2xvcjYzZWYwMTogRkMgPSAoeyBjaGlsZHJlbiB9KSA9PiA8c3BhbiBjc3M9e2NvbG9yNjNlZjAxfT57Y2hpbGRyZW59PC9zcGFuPlxuY29uc3QgY29sb3I3YTJhNDggPSBjc3NgZGlzcGxheTogaW5saW5lLWJsb2NrOyB3aWR0aDogMWVtOyB0ZXh0LWluZGVudDogLTk5OTllbTsgYmFja2dyb3VuZDogIzdhMmE0ODtgO1xuICAgICAgICAgIGNvbnN0IENvbG9yN2EyYTQ4OiBGQyA9ICh7IGNoaWxkcmVuIH0pID0+IDxzcGFuIGNzcz17Y29sb3I3YTJhNDh9PntjaGlsZHJlbn08L3NwYW4+XG5jb25zdCBjb2xvcmIzOWMzOSA9IGNzc2BkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IHdpZHRoOiAxZW07IHRleHQtaW5kZW50OiAtOTk5OWVtOyBiYWNrZ3JvdW5kOiAjYjM5YzM5O2A7XG4gICAgICAgICAgY29uc3QgQ29sb3JiMzljMzk6IEZDID0gKHsgY2hpbGRyZW4gfSkgPT4gPHNwYW4gY3NzPXtjb2xvcmIzOWMzOX0+e2NoaWxkcmVufTwvc3Bhbj5cbmNvbnN0IGNvbG9yZjczMWQ0ID0gY3NzYGRpc3BsYXk6IGlubGluZS1ibG9jazsgd2lkdGg6IDFlbTsgdGV4dC1pbmRlbnQ6IC05OTk5ZW07IGJhY2tncm91bmQ6ICNmNzMxZDQ7YDtcbiAgICAgICAgICBjb25zdCBDb2xvcmY3MzFkNDogRkMgPSAoeyBjaGlsZHJlbiB9KSA9PiA8c3BhbiBjc3M9e2NvbG9yZjczMWQ0fT57Y2hpbGRyZW59PC9zcGFuPlxuY29uc3QgY29sb3JkZTUxOTUgPSBjc3NgZGlzcGxheTogaW5saW5lLWJsb2NrOyB3aWR0aDogMWVtOyB0ZXh0LWluZGVudDogLTk5OTllbTsgYmFja2dyb3VuZDogI2RlNTE5NTtgO1xuICAgICAgICAgIGNvbnN0IENvbG9yZGU1MTk1OiBGQyA9ICh7IGNoaWxkcmVuIH0pID0+IDxzcGFuIGNzcz17Y29sb3JkZTUxOTV9PntjaGlsZHJlbn08L3NwYW4+XG5cbiAgICAgIGV4cG9ydCBjb25zdCBGaWxlNzk6IFZGQyA9ICgpID0+IChcbiAgICAgICAgPHA+XG4gICAgICAgICAgPENvbG9yNzA2MDhkPjcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDcwNjA4ZDwvQ29sb3I3MDYwOGQ+ICAgICAgICAgIFxuPENvbG9yZjgzZTcxPmY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MWY4M2U3MTwvQ29sb3JmODNlNzE+ICAgICAgICAgIFxuPENvbG9yNzgxMDc2Pjc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3Njc4MTA3NjwvQ29sb3I3ODEwNzY+ICAgICAgICAgIFxuPENvbG9yYzQzZjk0PmM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NGM0M2Y5NDwvQ29sb3JjNDNmOTQ+ICAgICAgICAgIFxuPENvbG9yODRkYmJhPjg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTg0ZGJiYTwvQ29sb3I4NGRiYmE+ICAgICAgICAgIFxuPENvbG9yOTE0YzI0PjkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDkxNGMyNDwvQ29sb3I5MTRjMjQ+ICAgICAgICAgIFxuPENvbG9yYjEwMzg1PmIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NWIxMDM4NTwvQ29sb3JiMTAzODU+ICAgICAgICAgIFxuPENvbG9yZjJhYzFiPmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYmYyYWMxYjwvQ29sb3JmMmFjMWI+ICAgICAgICAgIFxuPENvbG9yMDkzZmY5PjA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTA5M2ZmOTwvQ29sb3IwOTNmZjk+ICAgICAgICAgIFxuPENvbG9yZjNlYjY2PmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NmYzZWI2NjwvQ29sb3JmM2ViNjY+ICAgICAgICAgIFxuPENvbG9yZWMwZmMxPmVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMWVjMGZjMTwvQ29sb3JlYzBmYzE+ICAgICAgICAgIFxuPENvbG9yNjY5OGM5PjY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTY2OThjOTwvQ29sb3I2Njk4Yzk+ICAgICAgICAgIFxuPENvbG9yMTFjMzM0PjExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDExYzMzNDwvQ29sb3IxMWMzMzQ+ICAgICAgICAgIFxuPENvbG9yMzNkMGM0PjMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDMzZDBjNDwvQ29sb3IzM2QwYzQ+ICAgICAgICAgIFxuPENvbG9yOTA2ZDk5PjkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTkwNmQ5OTwvQ29sb3I5MDZkOTk+ICAgICAgICAgIFxuPENvbG9yNjNlZjAxPjYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTYzZWYwMTwvQ29sb3I2M2VmMDE+ICAgICAgICAgIFxuPENvbG9yN2EyYTQ4PjdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODdhMmE0ODwvQ29sb3I3YTJhNDg+ICAgICAgICAgIFxuPENvbG9yYjM5YzM5PmIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOWIzOWMzOTwvQ29sb3JiMzljMzk+ICAgICAgICAgIFxuPENvbG9yZjczMWQ0PmY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNGY3MzFkNDwvQ29sb3JmNzMxZDQ+ICAgICAgICAgIFxuPENvbG9yZGU1MTk1PmRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NWRlNTE5NTwvQ29sb3JkZTUxOTU+XG4gICAgICAgIDwvcD5cbiAgICAgICk7XG4gICJdfQ== */",
  toString: _EMOTION_STRINGIFIED_CSS_ERROR__
};
LukasBombach commented 2 years ago

Others are reporting this at the Webpack Dev Server Repo as well

https://github.com/webpack/webpack-dev-server/issues/1433#issuecomment-1064188349

Emotion seems involved as well.

By now, what I have noticed: The memory appears completely stable. I've been taking regular snapshots over the span of an hour, everything stayed stable at about 18MB. Then, in an instance, there's 4GB of memory allocation and a crash.

I had one curious case where this happened the moment I added a debugger; statement with open dev tools, but that may have been a cooincidence.

Also something else I am curious of: It may have started at our project when I intoduced a webpack child compiler. When I did research on this issue I found that often times issues were related to Webpack plugins that use child compilers. But I that is also a shot in the dark to some degree.

JulienKode commented 2 years ago

I have the same issue with 12.1

And setting:

experimental: {
    esmExternals: false, 
  },

Does not change the issue

I'll try to do a reproduction repo

I also use next-transpile-module

balazsorban44 commented 2 years ago

For those using next-transpile-module, you might want to follow #35150.

ddzieduch commented 2 years ago

I have created a repository nextjs-dynamic-amcharts with the example of the smallest reproduction of the problem..

@balazsorban44 @timneutkens take a look.

LukasBombach commented 2 years ago

@ddzieduch can you describe the steps to take how to trigger the heap overflow?

ddzieduch commented 2 years ago

  1. npm i

  2. add "type": "module" to node_modules/@amcharts/amcharts4/package.json and node_modules/@amcharts/amcharts4-geodata/package.json

  3. npm run build

@LukasBombach

pstoica commented 2 years ago

Fixed once I realized that esmExternals: false goes under experimental, not the root config 🤦

My issue is from using an Nx/Yarn v1 monorepo. It happened with both externalDir and withTM. It also affected runtime somehow. So relieved I figured it out.

Before (needed --max-old-space-size): Screen Shot 2022-04-01 at 4 20 54 PM

After: Screen Shot 2022-04-01 at 4 20 57 PM

nilanjansiromani commented 2 years ago

i was able to get around this issue by turning the esmexternals flag to false

the way i see, this is the only config change needed to get around this issue

do note this goes under experimentals not the root config like mentioned above

nilanjansiromani commented 2 years ago

marking this as closed for now thanks everyone for your inputs