good news guys, I have upgraded to latest version of angular and cli (12.1.3). I no longer facing OOM issue anymore during serving. I am not able to take the memory heap snapshot as it used up alot of memory to do that, thus i recorded down the memory usage based on task manager as a reference:

Before (12.1.0) Memory usage for each rebuild (MB): 5731 -> 5739 -> 6313 -> BOMB (normally will OOM not more than 5 times rebuild) Average rebuild duration: ~1m30s

After (12.1.3) Memory usage for each rebuild (MB): 5562 -> 5328 -> 5388 -> 5484 -> (will increase and decrease, but stay below 6gb) Average rebuild duration: ~10 - 30s

Note: I use --max_old_space_size=6000 in my project

No significant improve in cold build, thus I suspect it might related to this. https://github.com/angular/angular/pull/42759

Angular CLI: 12.1.3
Node: 14.17.0
Package Manager: npm 6.14.13
OS: win32 x64

Angular: 12.1.3
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, language-service, material, platform-browser       
... platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1201.3
@angular-devkit/build-angular   12.1.3
@angular-devkit/core            12.1.3
@angular-devkit/schematics      12.1.3
@angular/flex-layout            12.0.0-beta.34
@schematics/angular             12.1.3
rxjs                            6.6.7
typescript                      4.3.5

Version 12.1.0 has been released which contains several performance improvements. We also introduced an experimental file system cache which should improve the second/warm build quite a lot. You can opt-in using the NG_PERSISTENT_BUILD_CACHE=1 environment variable.

Please update using ng update @angular/cli @angular/core.

If the issue persist please report back providing one of the following;

• CPU profile, memory snapshots and angular.json configuration
• Reproduction (Even shared privately).

Same happens to me throughout my day, usually around 5 times a day. Any pointer to how to get memory heap snapshots for ng serve when this happens? (actually I use nx, so it’s nx serve)

After several hours of ng serve running (sometimes can be less than hour or 10 min) it crashes:

<--- Last few GCs --->

[18744:0000025A362E33E0]  1923405 ms: Scavenge 3922.4 (4112.8) -> 3907.0 (4112.8) MB, 7.6 / 0.0 ms  (average mu = 0.209, current mu = 0.165) allocation failure
[18744:0000025A362E33E0]  1923790 ms: Scavenge 3925.1 (4114.2) -> 3914.2 (4114.2) MB, 13.8 / 0.0 ms  (average mu = 0.209, current mu = 0.165) allocation failure 
[18744:0000025A362E33E0]  1924001 ms: Scavenge 3928.4 (4116.1) -> 3920.1 (4116.2) MB, 10.3 / 0.0 ms  (average mu = 0.209, current mu = 0.165) allocation failure 


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF74F7D481F napi_wrap+110783
 2: 00007FF74F777F26 v8::base::CPU::has_sse+61862
 3: 00007FF74F778E26 node::OnFatalError+294
 4: 00007FF7500522EE v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF7500370BD v8::SharedArrayBuffer::Externalize+781
 6: 00007FF74FEE01FC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1516
 7: 00007FF74FEEB61A v8::internal::Heap::ProtectUnprotectedMemoryChunks+1258
 8: 00007FF74FEE8759 v8::internal::Heap::PageFlagsAreConsistent+2457
 9: 00007FF74FEDD301 v8::internal::Heap::CollectGarbage+2049
10: 00007FF74FEDB505 v8::internal::Heap::AllocateExternalBackingStore+1349
11: 00007FF74FEF5385 v8::internal::GCIdleTimeHandler::ShouldDoContextDisposalMarkCompact+1029
12: 00007FF74FEF57D5 v8::internal::Factory::AllocateRaw+37
13: 00007FF74FF09316 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller+86
14: 00007FF74FF09623 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithMap+35
15: 00007FF74FD0FBBC v8::internal::OrderedHashTable<v8::internal::OrderedHashSet,1>::Allocate+124
16: 00007FF74FD1267A v8::internal::OrderedHashTable<v8::internal::OrderedHashSet,1>::Rehash+58
17: 00007FF74FD1111A v8::internal::OrderedHashTable<v8::internal::OrderedHashSet,1>::EnsureGrowable+90
18: 00007FF74FC47CB7 v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+123479
19: 00007FF7500DB1AD v8::internal::SetupIsolateDelegate::SetupHeap+465325
npm ERR! NGA@0.0.0 StartDevelopmentServerMaxSize: `node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng serve`
npm ERR! Exit status 134
npm ERR!
npm ERR! Failed at the NGA@0.0.0 StartDevelopmentServerMaxSize script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\oifrah\AppData\Roaming\npm-cache\_logs\2021-07-19T21_42_46_915Z-debug.log

Angular CLI: 12.1.1 Node: 14.17.1 Package Manager: npm 6.14.13 OS: win32 x64

Angular: 12.1.1 … animations, cdk, cli, common, compiler, compiler-cli, core … forms, language-service, localize, material … platform-browser, platform-browser-dynamic, router

Package Version

@angular-devkit/architect 0.1201.1 @angular-devkit/build-angular 12.1.1 @angular-devkit/core 12.1.1 @angular-devkit/schematics 12.1.1 @schematics/angular 12.1.1 rxjs 6.5.5 typescript 4.3.5

1. Check your build settings

As I understand some build defaults changed in Angular 12. If you migrated from a previous Angular version, first make sure that the migration got the correct settings for your development build (ng serve):

"vendorChunk": true,      // use only in dev
"extractLicenses": false,
"buildOptimizer": false,  // turn off only in dev
"sourceMap": true,
"optimization": false,    // turn off only in dev
"namedChunks": true

"aot": true,              // omit or set to true
"outputHashing": "none",  // omit or set to none (only in dev, you probably want "all" for production)

important: keep in mind that you may have repeated properties in architect.build.options and in architect.build.configurations.development and ng serve will use the merge of those.

2. Increase node’s memory

Node >= 12 will use a maximum of 2GB for heap memory. You can increase this using a flag, but that requires rewriting you ng serve script in package.json like this:

"scripts": {
   "start": "node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng serve",
   ...
 }

Then you can use npm start to run your dev server.

This will give you more compilations, but in the end it will still crash, until the actual memory leaks are fixed.

@alan-agius4 This is the test i did, crashed after 10 minutes of use. On Monday I will send you a snapshot of the memory

https://docs.google.com/document/d/1nzjpJXWU5n7fCV2Yym-yeHZ9VuiykvVqVR8ZL8yLBHk/edit?usp=sharing

Hi all,

Just want to re-cap what is happening in this issue, since there are a lot of comments and important information gets lost.

• A number of performance improvements have landed in the Angular CLI, Webpack and other transitive dependencies, which should improve performance.
• If you are using 3rd party builders, check your angular.json configuration and verify that you are not running “production” builds during development. (see: https://github.com/angular/angular-cli/issues/20801#issuecomment-850334411)
• Webpack 5 does use slightly more memory due to the in-memory caching but so far from the reviewed snapshots no reports indicate that there is a memory leak. What I saw was that the OOM happened on projects that were already close to the Node.JS memory limit in version 11.

If you are on 12.0.3, and still experiencing OOM during re-builds please report back with with heap snapshots. I’ll leave this issue open for a couple of days until people provide confirmation that the issue is no longer preset or/and repros/heap snapshots.

The workaround I have found is run ng serve in this way:

node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng serve

otherwise node crash

@anton-white are you using angular material theming?

for me compile time issue was because of the following lines

@use '~@angular/material' as mat;
@import "~@angular/material/theming";

ng update added the @use but kept second line. After removing that (https://github.com/angular/components/issues/22676#issuecomment-839877758) compile time has improved by a lot. memory usage is still high.

CLI on 12.2.0 still has the same issue, and even with --max_old-space-size=12000.

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1201.2
@angular-devkit/build-angular   12.1.4
@angular-devkit/core            12.2.0
@angular-devkit/schematics      12.2.0
@angular/compiler-cli           12.1.5
@angular/fire                   6.1.4
@angular/language-service       12.1.5
@schematics/angular             11.0.1
ng-packagr                      12.1.1
rxjs                            6.6.7
typescript                      4.2.4
webpack                         5.42.0

    "@angular/animations": "^12.1.3",
    "@angular/cdk": "^12.1.3",
    "@angular/common": "^12.1.3",
    "@angular/compiler": "^12.1.3",
    "@angular/core": "^12.1.3",
    "@angular/fire": "^6.1.4",
    "@angular/forms": "^12.1.3",
    "@angular/google-maps": "^12.1.3",
    "@angular/material": "^12.1.3",
    "@angular/material-moment-adapter": "^12.1.3",
    "@angular/platform-browser": "^12.1.3",
    "@angular/platform-browser-dynamic": "^12.1.3",
    "@angular/router": "^12.1.3",
...

<--- Last few GCs --->

[23402:0x104909000] 17212286 ms: Scavenge (reduce) 11919.6 (12022.0) -> 11918.7 (12023.0) MB, 11.4 / 0.0 ms  (average mu = 0.085, current mu = 0.060) allocation failure
[23402:0x104909000] 17212317 ms: Scavenge (reduce) 11919.7 (12022.0) -> 11918.9 (12023.0) MB, 10.9 / 0.0 ms  (average mu = 0.085, current mu = 0.060) allocation failure
[23402:0x104909000] 17212338 ms: Scavenge (reduce) 11919.7 (12022.0) -> 11919.0 (12023.0) MB, 14.6 / 0.0 ms  (average mu = 0.085, current mu = 0.060) allocation failure


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x101317585 node::Abort() (.cold.1) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 2: 0x1000b25c9 node::Abort() [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 3: 0x1000b272f node::OnFatalError(char const*, char const*) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 4: 0x1001f6eb7 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 5: 0x1001f6e53 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 6: 0x1003a6eb5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 7: 0x1003a897a v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 8: 0x1003a4049 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
 9: 0x1003a18e1 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
10: 0x1003b019a v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
11: 0x1003b0221 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
12: 0x100380160 v8::internal::Factory::NewProperSubString(v8::internal::Handle<v8::internal::String>, int, int) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
13: 0x100725fc1 v8::internal::Runtime_StringSplit(int, unsigned long*, v8::internal::Isolate*) [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
14: 0x100a8a919 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
15: 0x100a7c5bf Builtins_StringPrototypeSplit [/Users/iam/.nvm/versions/node/v14.17.3/bin/node]
16: 0x93a5d85afe

Jumping in here. I am experiencing the same OOM crashes after upgrading to v12.

I am open to share privately my repo to you @alan-agius4 or anybody who could investigate the issue. Falling back to v11 now, because ng serve doesn’t work anymore. Thanks for looking into it!

Edit: Same after latest upgrades:

Angular CLI: 12.0.2
Node: 14.16.0
Package Manager: yarn 1.22.5
OS: linux x64

Angular: 12.0.2
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, language-service, localize, material
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1200.1
@angular-devkit/build-angular   12.0.2
@angular-devkit/core            12.0.2
@angular-devkit/schematics      12.0.2
@angular/flex-layout            12.0.0-beta.34
@schematics/angular             12.0.2
rxjs                            6.6.7
typescript                      4.2.4

Anyone is still experiencing this issue with ng serve in 12.0.1 or later?

@alan-agius4 How can produce a memory snapshot of ng serve for help to solve this issue?

1. node --inspect-brk node_modules/@angular/cli/lib/init.js serve
2. Open Chrome and type chrome://inspect in the address bar
3. Click on the inspect button from one of your applications in the Remote Target section.
4. Go to Chrome DevTools > Memory
5. Take a heap snapshot
6. Perform the action that causes OOM

Repeat the last 2 until the OOM error is shown, once done, save the last couple of snapshots and send them over.

I spent some times looking into a project that does show OOM issues during rebuilds. The project in question was provided by @ganySA privately. (Thanks a lot for this).

What I found out from my investigation on the mentioned project is;

• A non incremental build uses around ~1.7/1.8Gb of memory
• After the first rebuild this increases to ~1.9/2Gb and keep in this range after multiple rebuilds
• Disabling Webpack 5 memory caching does keep the memory usage consistent between the first and second build
• The OOM happens when a re-build is triggered before GC kicks in a frees up the memory
• Reverting the project to Webpack 4 used the same amount of memory that Webpack 5 uses when caching is disabled

To sum it up, from the project I look at, it doesn’t appear that there is a memory leak as memory usage stays within the same range over a number of rebuilds but rather the increase in memory usage is to be attributed to Webpack 5 caching.

Note: there are number of options such as outputHashing being enabled and namedChunks being disabled can contribute to a memory leak when used in watch mode.

That said, without a reproduction even shared privately or memory snapshots, we will not be able to determine if there is a memory leak, or it’s just the expected increase of memory usage due to Webpack 5 caching, in the upcoming release we also shifted SASS to be processed in workers which should help reduce memory pressure on the main thread since workers have a dedicated memory pool.

I upgraded to Angular 13.1.3 hoping that this issue would go away, but it’s still there 😦

FYI for us, removing an heavy css import fixed the problem.

We were including a ~1MB+ stylesheet in one of our .scss file… which started to trigger this issue after upgrading to Angular 12. We circumvented that by including it directly in index.html. That’s a bit dirty, but at least it seems to have made Angular usable again.

@alan-agius4 I’ve been running into this issue as well. I’ve attached some memory snapshots. At the point where the process ran out of memory it was using 4GB of memory.

Angular CLI: 12.2.2 Node: 16.7.0 (Unsupported) Package Manager: npm 7.20.3 OS: darwin x64

Angular: 12.2.2 … animations, cdk, cli, common, compiler, compiler-cli, core … forms, language-service, platform-browser … platform-browser-dynamic, platform-server, pwa, router … service-worker

Package Version

@angular-devkit/architect 0.1201.4 @angular-devkit/build-angular 12.2.2 @angular-devkit/core 12.2.2 @angular-devkit/schematics 12.2.2 @nguniversal/builders 12.1.0 @nguniversal/express-engine 12.1.0 @schematics/angular 12.2.2 ng-packagr 12.0.5 rxjs 6.6.3 typescript 4.2.4

Archive.zip

@devhus, can you please explain how to get the OOM? I didn’t manage to replicate this locally.

The error is thrown while changing the project code and saving files to live rebuild & reload the app. As you rebuild the project while serving it, it will keep increasing the memory usage until it crashes. What i think is that somehow NodeJs don’t manage to clear the memory used for the first serve session and each rebuild creates another session without destroying the old one. So serving the project without having cli to rebuild the project won’t replicate the error.

any updates?

I had the same problem, where the ng build command would fail with OOM errors (Angular 12.0.4). It seems to be fixed after using the following properties in angular.json (meaning the build finished, but I’m not sure if the problem is fixed or if it will reappear; I will come back with an update if it fails again):

"outputHashing": "all",
"namedChunks": true,
"extractLicenses": false,
"vendorChunk": true,
"buildOptimizer": false,
"sourceMap": true

OOM errors are also thrown by ng serve after a while. It is also noticeably slower than previous Angular versions. It also seems to be triggering more recompiles than previous versions (i.e. not only on file save), but I think this behavior is intended?

Since upgrading to Angular 12 we are getting OOM (error 137) error during CI/CD build on Azure DevOps.

We have tried the following without success:

• –max-old-space-size using an environment variable.
• Setting NG_BUILD_MAX_WORKERS=1
• Downgrading @angular-devkit/build-angular to v12.0.0

On my Macbook 16" 2020 with 32GB of RAM i can build the app using ng build --configuration production

We built a Ubunt Linux VM with similar memory constraints as the Hosted Azure DevOps build agent and attempted a build which failed with error 137 OOM.

Regards, Tarek

I am encountering the same problem after the upgrade to 12.0.1 (Node.js version used is 14.17.0) ng build -c production results in OOM every time. ng serve and ng test are working fine.

Yesterday release (12.0.1) contains several performance improvements. Please give it a try!

@pmoleri , I’ve got everything you mentioned in there, except sadly only "aot": true is not enabled for dynamic html rendering

I don’t have large files in angular. It just consumes up to 2.9 gb and during build, it’d go up to 3.5 gb. I have zero idea why whould serve take that much space. The project is huge and this was pain but nothing is clear about whys here.

I had to ditch Ng serve completely and use Ng build with nodemon and angular 13. Since angular 13 caches build. This helped as a workaround with a great difference. Now angular consumes 50mb runtime and 1 gb during build.

I still wonder why build would go that much high. It’s just frontend. Nestjs (backend) does tons better job than angular in this.

Sadly this is not an issue with Angular, but with Webpack: https://github.com/webpack/webpack/issues/12771

I used to crash after every change, but after minifying (any simplifying) JSON files from 500Mb to 50Mb, the crashes are gone. So my suggestion is to look for large imported files and try not to import them if possible.

I have just updated to nx 13.1.3 and Angular 12.x.x and my server build crashes! I do usually run the server with the command nx serve server and now it crashes after every change. Do nx team still need reproduction repositories?

Additional info: Due to upgrading problems I removed node_modules and package_lock prior install. Thus it is a pretty clean repository now.

19.11.2021:

Updated to nx v13.2.0 and angular v~13.0.0, the error is still there. (Also npm was not able to update, had to use yarn)

Updated to 12.2.0, it seems better now.

I keep getting errors about this:

^12.1.4 版本没问题了，可以了。打包速度很快。

I’m on Angular 12.2.0 and it keeps happening all the time.

@oshri551, please share the output of ng v together with memory heap snapshots.

@devhus, can you please explain how to get the OOM? I didn’t manage to replicate this locally.

The error is thrown while changing the project code and saving files to live rebuild & reload the app. As you rebuild the project while serving it, it will keep increasing the memory usage until it crashes. What i think is that somehow NodeJs don’t manage to clear the memory used for the first serve session and each rebuild creates another session without destroying the old one. So serving the project without having cli to rebuild the project won’t replicate the error.

I did run several re-builds but the memory usage was consistent. So, if there is leak it might be related to a specific change, what changed do I need to do to trigger the OOM? Also, can you please provide the output of ng v?

I also, was able to build the project with incremental builds without needing to increase the memory limit (Ie, by omitting max_old_space_size). Setting a high max_old_space_size will increase memory usage, because GC will run less often to remove unused objects. if you set it too high, additionally setting this too hight might cause your system to run out of memory.

In your case you set the memory limit to 8Gb, can you confirm that you have at least 9Gb of free memory? Also, unless max_old_space_size is truly needed, I recommand to don’t use it.

i have no idea what you can do to trigger it, it just happen as i am working i can’t keep tracking of memory while doing that.

Angular CLI: 12.1.0
Node: 14.17.0
Package Manager: npm 6.14.13
OS: win32 x64

Angular: 12.1.0
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, language-service, localize, platform-browser
... platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1201.0
@angular-devkit/build-angular   12.1.0
@angular-devkit/core            12.1.0
@angular-devkit/schematics      12.1.0
@schematics/angular             12.1.0
rxjs                            6.6.7
typescript                      4.3.4

but i didn’t mean that you need to use ng build command, what i meant is the live-rebuild that happens when you change files while serving the project with ng serve

without using max_old_space_size setting the project crashes much more faster.

i have 32gb rams, don’t think my pc really getting out of memory… NodeJs just reaches 8GB while serving the project and crashes since it’s the allowed limit for it.

@devhus, please provide at least one of the following, otherwise we will be unable to get investigate your issue.

• CPU profile, memory snapshots (initial and rebuilds) and angular.json configuration
• Reproduction (Even shared privately).

Hi @legrottagliegionata, let’s keep this issue focused on OOM errors. If you are experiencing a different problem ideally please open a new issue.

Those are surprising, I think. So it does appear there’s a a memory leak somewhere, as an incremental build adds some 300MBs of extra memory usage. I am especially surprised by the 3 builds where it stayed at 3GB, then grew further in the sixth build. I haven’t seen that behavior in a test project I have been using; the usage was at 1.8GB after the initial build and grew to 2.2GB after rebuilds, but it appeared to stay at that level.

@legrottagliegionata Could you try with latest @angular/compiler-cli snapshots:

npm install git+https://github.com/angular/compiler-cli-builds.git#d0ddff32e5e8cc159950a1aebb9aaae5a3d82644

It includes a fix for a memory leak, which unfortunately has missed the 12.0.4 release. The above sha refers to the 12.0.x version of @angular/compiler-cli so should be a drop-in replacement.

The problem is still there. Do you want more snapshots?

No need thanks

We experience the same problems in version 12.0.3. It typically happens when I change the branch (this leads to many changes in different files at the same time) and an incremental build is triggered.

Hi all, yes, I’m still experiencing issues:

Hey, I’m having the same problem:

<--- Last few GCs --->

[10664:0000021FC8C2FE50]  4891817 ms: Scavenge 2017.3 (2050.6) -> 2012.6 (2052.6) MB, 23.5 / 0.0 ms  (average mu = 0.549, current mu = 0.519) allocation failure

[10664:0000021FC8C2FE50]  4893105 ms: Mark-sweep 2038.7 (2072.3) -> 2026.3 (2076.7) MB, 1126.9 / 0.1 ms  (average mu = 0.466, current mu = 0.329) allocation fai
lure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
 1: 00007FF722F53E0F napi_wrap+108911
 2: 00007FF722EF7E16 v8::base::CPU::has_sse+61910
 3: 00007FF722EF8D16 node::OnFatalError+294
 4: 00007FF7237D0CEE v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF7237B5ACD v8::SharedArrayBuffer::Externalize+781
 6: 00007FF72365F95C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1516
 7: 00007FF72364A4DB v8::internal::NativeContextInferrer::Infer+59451
 8: 00007FF72362F8FF v8::internal::MarkingWorklists::SwitchToContextSlow+56991
 9: 00007FF72364358B v8::internal::NativeContextInferrer::Infer+30955
10: 00007FF72363A6AD v8::internal::MarkCompactCollector::EnsureSweepingCompleted+6269
11: 00007FF7236427DE v8::internal::NativeContextInferrer::Infer+27454
12: 00007FF72364679B v8::internal::NativeContextInferrer::Infer+43771
13: 00007FF7236500E2 v8::internal::ItemParallelJob::Task::RunInternal+18
14: 00007FF723650071 v8::internal::ItemParallelJob::Run+641
15: 00007FF723623863 v8::internal::MarkingWorklists::SwitchToContextSlow+7683
16: 00007FF72363AB5C v8::internal::MarkCompactCollector::EnsureSweepingCompleted+7468
17: 00007FF7236393A4 v8::internal::MarkCompactCollector::EnsureSweepingCompleted+1396
18: 00007FF723636F28 v8::internal::MarkingWorklists::SwitchToContextSlow+87240
19: 00007FF723665721 v8::internal::Heap::LeftTrimFixedArray+929
20: 00007FF723667815 v8::internal::Heap::PageFlagsAreConsistent+789
21: 00007FF72365CA71 v8::internal::Heap::CollectGarbage+2033
22: 00007FF72365AC95 v8::internal::Heap::AllocateExternalBackingStore+1349
23: 00007FF723674A05 v8::internal::GCIdleTimeHandler::ShouldDoContextDisposalMarkCompact+1029
24: 00007FF723674E55 v8::internal::Factory::AllocateRaw+37
25: 00007FF7236892FB v8::internal::FactoryBase<v8::internal::Factory>::NewRawOneByteString+75
26: 00007FF72347D15C v8::internal::String::SlowFlatten+396
27: 00007FF72332BF80 unibrow::Utf8::EncodeOneByte+656
28: 00007FF7237DD9DF v8::String::WriteUtf8+175
29: 00007FF722E191F3 v8::internal::HashTable<v8::internal::EphemeronHashTable,v8::internal::EphemeronHashTableShape>::HashTable<v8::internal::EphemeronHashTable
,v8::internal::EphemeronHashTableShape>+37363
30: 00007FF722DC40EC v8_inspector::protocol::Binary::operator=+20092
31: 00007FF722DBCDD4 uv_loop_size+35268
32: 00007FF7237F2F1C v8::internal::SetupIsolateDelegate::SetupHeap+44220
33: 000003EDCA6D4CB0
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! avsi-app@1.0.66 start: `ng serve --open`
npm ERR! Exit status 134

Although it appears minutes/hours (30 minutes/2 hours) after starting angular and developing.

Well I don’t have a memory snapshot but I’ll be watching to get it next time it happens.

Thanks!

great work, @legrottagliegionata

@qortex, It appears that for development builds you are using production settings.

This is because a migration was not run during ng-update because you are using unofficial builders and we cannot know how these builders interact with the builder options and therefore we cannot modify the configuration.

As such it is recommend that such builders provide their own ng-update migration or at least document what needs to change for version 12.

Adding the below to projects.app.architect.build.options should make things better.

"vendorChunk": true,
"extractLicenses": false,
"buildOptimizer": false,
"sourceMap": true,
"optimization": false,
"namedChunks": true

@ale-mazz, unfortunately, the dump is not helpful. Without at a memory heap and cpu profile we will not be able to get to the bottom of your issue.

@alan-agius4 Pasting here my stacktrace, unfortunately i can’t share with you my project cause company’s limitations.

⠋ Generating browser application bundles...
<--- Last few GCs --->

[29405:0x5ba1bc0]   460574 ms: Mark-sweep (reduce) 2033.4 (2081.5) -> 2032.3 (2081.3) MB, 3601.4 / 0.1 ms  (average mu = 0.088, current mu = 0.043) allocation failure GC in old space requested
[29405:0x5ba1bc0]   463517 ms: Mark-sweep (reduce) 2032.3 (2081.3) -> 2032.3 (2081.0) MB, 2943.3 / 0.1 ms  (average mu = 0.048, current mu = 0.000) allocation failure GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb14d40 node::Abort() [ng serve app-synergy --port 4200 --open true]
 2: 0xa31e30 node::FatalError(char const*, char const*) [ng serve app-synergy --port 4200 --open true]
 3: 0xcfb92e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ng serve app-synergy --port 4200 --open true]
 4: 0xcfbca7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ng serve app-synergy --port 4200 --open true]
 5: 0xee5f45  [ng serve app-synergy --port 4200 --open true]
 6: 0xee6a8c  [ng serve app-synergy --port 4200 --open true]
 7: 0xef49c1 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ng serve app-synergy --port 4200 --open true]
 8: 0xef7f1c v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ng serve app-synergy --port 4200 --open true]
 9: 0xebbdc5 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [ng serve app-synergy --port 4200 --open true]
10: 0xeb6c69 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [ng serve app-synergy --port 4200 --open true]
11: 0xeb6d24 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [ng serve app-synergy --port 4200 --open true]
12: 0x103ec4e  [ng serve app-synergy --port 4200 --open true]
13: 0x1053db8  [ng serve app-synergy --port 4200 --open true]
14: 0x105409a  [ng serve app-synergy --port 4200 --open true]
15: 0x10aee5a v8::internal::JSObject::AddDataElement(v8::internal::Handle<v8::internal::JSObject>, unsigned int, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes) [ng serve app-synergy --port 4200 --open true]
16: 0x10f10f1 v8::internal::Object::AddDataProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::Maybe<v8::internal::ShouldThrow>, v8::internal::StoreOrigin) [ng serve app-synergy --port 4200 --open true]
17: 0x10f52cf v8::internal::Object::SetProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::StoreOrigin, v8::Maybe<v8::internal::ShouldThrow>) [ng serve app-synergy --port 4200 --open true]
18: 0x1247655 v8::internal::Runtime::SetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::StoreOrigin, v8::Maybe<v8::internal::ShouldThrow>) [ng serve app-synergy --port 4200 --open true]
19: 0x1248777 v8::internal::Runtime_SetKeyedProperty(int, unsigned long*, v8::internal::Isolate*) [ng serve app-synergy --port 4200 --open true]
20: 0x16119d9  [ng serve app-synergy --port 4200 --open true]

Before angular v12 we were able to run it without giving node more than 2gbs of memory, now it crashes even with 6gbs of memory.

I tried installing 64bit node and it worked fine and resolved my issue.

This saved me! Thank you

Anyone is still experiencing this issue with ng serve in 12.0.1 or later?

Yes… after a lot of code changes it crash

I am encountering the same problem after the upgrade to 12.0.1 (Node.js version used is 14.17.0) ng build -c production results in OOM every time. ng serve and ng test are working fine.

This could be related to this issue. There is already a fix in the pipeline. As a temporary fix for now, you can downgrade just the @angular-devkit/build-angular to v12.0.0 instead of v12.0.1 and retry the ng build -c production command.

In my case disabling styles optimizations in angular.json makes the build work again without crashing out of memory i have 32gb of RAM and compiling with --max-old-space-size=12288 makes the build crash.

One important thing that i’ve noticed is that the build start crashing after upgrading from project clarity 4 -> 5, i’m assuming that the build is crashing because of some bug on css processing libraries with “modern css”

Why would you have optimizations enabled during ng serve?

In my case disabling styles optimizations in angular.json makes the build work again without crashing out of memory i have 32gb of RAM and compiling with --max-old-space-size=12288 makes the build crash.

One important thing that i’ve noticed is that the build start crashing after upgrading from project clarity 4 -> 5, i’m assuming that the build is crashing because of some bug on css processing libraries with “modern css”