x
)- [x] bug report -> please search issues before submitting
- [ ] feature request
x
)- [ ] new
- [x] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
npm 6.4.1
yarn 1.9.4
Angular CLI: 7.0.1
Node: 8.12.0
OS: darwin x64
Angular: 7.0.0
... animations, cdk, common, compiler, compiler-cli, core, forms
... http, language-service, material, material-moment-adapter
... platform-browser, platform-browser-dynamic, platform-server
... router, service-worker
@angular-devkit/architect 0.10.1
@angular-devkit/build-angular 0.10.1
@angular-devkit/build-optimizer 0.10.1
@angular-devkit/build-webpack 0.10.1
@angular-devkit/core 7.0.1
@angular-devkit/schematics 7.0.1
@angular/cli 7.0.1
@angular/pwa 0.10.1
@ngtools/webpack 7.0.1
@schematics/angular 7.0.1
@schematics/update 0.10.1
rxjs 6.3.3
typescript 3.1.3
webpack 4.19.1
run ng build client --prod
92% chunk asset optimization TerserPlugin
<--- Last few GCs --->
[6911:0x102801e00] 224585 ms: Mark-sweep 1318.9 (1444.5) -> 1318.9 (1444.5) MB, 1195.0 / 0.0 ms allocation failure GC in old space requested
[6911:0x102801e00] 225921 ms: Mark-sweep 1318.9 (1444.5) -> 1318.9 (1429.5) MB, 1336.0 / 0.0 ms last resort GC in old space requested
[6911:0x102801e00] 227268 ms: Mark-sweep 1318.9 (1429.5) -> 1318.9 (1429.5) MB, 1347.5 / 0.0 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x130c21da5879 <JSObject>
1: /* anonymous */ [/node_modules/source-map/lib/source-node.js:~342] [pc=0xa501c16fd08](this=0x130cfc80c2f1 <JSGlobal Object>,chunk=0x130c584834b1 <String[1]: .>,original=0x130cc679e159 <Object map = 0x130cb6748611>)
2: SourceNode_walk [/node_modules/source-map/lib/source-node.js:~221] [pc=0xa501c57db1e](t...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/usr/local/bin/node]
2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
4: v8::internal::Factory::NewUninitializedFixedArray(int) [/usr/local/bin/node]
5: v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/usr/local/bin/node]
6: v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
7: 0xa501a5042fd
error Command failed with signal "SIGABRT".
v6 doesn't have any issue building the same app.
I can't shared any code as it's a big client project, and I suspect it the size that's causing the issue as basic apps build ok.
I think the difference between v6 and v7 is the bug reported in https://github.com/angular/angular-cli/issues/12646 as in that issue production builds are taking longer, which usually indicated that more code is being processed and more memory is needed.
The general issue for running out of memory is https://github.com/angular/angular-cli/issues/5618. As projects grow bigger, they use more memory, and might need to increase the default memory limit. There's more information on this in https://github.com/angular/angular-cli/issues/5618#issuecomment-431310735.
In your case the only thing you did was to update from v6 to v7 and it should not need significantly more memory than before. I'll look at that problem in https://github.com/angular/angular-cli/issues/12646.
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build client --prod
allows build to complete, just need to know why my bundle has increase by 260kb
The same exact behaviour here. And the same solution worked...thank you dottodot!
try to modify the files and replace their contents with the following: (in the folder : node_modules\bin)
Modify ng.cmd:
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" --max_old_space_size=5048 "%~dp0\..\angular-cli\bin\ng" %*
) ELSE (
@SETLOCAL
@SET PATHEXT=%PATHEXT:;.JS;=;%
node --max_old_space_size=5048 "%~dp0\..\angular-cli\bin\ng" %*
)
Modify ngc.cmd :
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" --max_old_space_size=5048 "%~dp0\..\@angular\compiler-cli\src\main.js" %*
) ELSE (
@SETLOCAL
@SET PATHEXT=%PATHEXT:;.JS;=;%
node --max_old_space_size=5048 "%~dp0\..\@angular\compiler-cli\src\main.js" %*
)
My team was facing the same issue and this is how we resolved.
While building a project just use this command instead of ng build client --prod
node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --prod --build-optimizer
increase maximum memory allocated in angular.json
"budgets": [
{
"type": "initial",
"maximumWarning": "2mb",
"maximumError": "11mb"
}
]
I've faced this same problem recently and came across to this thread but my problem was with React
App. Below changes in the node start / build command solved my issues.
node --max-old-space-size=<size> path-to/fileName.js
node --max-old-space-size=16000 scripts/build.js
Basically, it varies depends on the allocated memory to that thread as per your node settings.
This is basically stay in our engine v8
. below code helps you to understand the Heap Size of your local node v8 engine.
const v8 = require('v8');
const totalHeapSize = v8.getHeapStatistics().total_available_size;
const totalHeapSizeGb = (totalHeapSize / 1024 / 1024 / 1024).toFixed(2);
console.log('totalHeapSizeGb: ', totalHeapSizeGb);
I am facing a similar issue on our app as well.
Angular 8.1.2
```> ng build --configuration=dev
92% chunk asset optimization TerserPlugin
<--- Last few GCs --->
[1296:0x102849000] 89061 ms: Mark-sweep 1344.5 (1447.4) -> 1334.0 (1450.4) MB, 529.6 / 0.0 ms (average mu = 0.150, current mu = 0.069) allocation failure scavenge might not succeed
[1296:0x102849000] 89634 ms: Mark-sweep 1347.2 (1450.4) -> 1336.7 (1452.9) MB, 530.6 / 0.0 ms (average mu = 0.113, current mu = 0.074) allocation failure scavenge might not succeed
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x36dcf845be3d]
Security context: 0x16484459e6e9
1: /* anonymous */ [0x1648cd39f4a9] [...node_modules/webpack-sources/node_modules/source-map/lib/source-node.js:~342] pc=0x36dcfb1746f2
2: SourceNode_walk [0x1648d8875019] [...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x10003cf99 node::Abort() [/usr/local/bin/node]
2: 0x10003d1a3 node::OnFatalError(char const, char const) [/usr/local/bin/node]
3: 0x1001b7835 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, bool) [/usr/local/bin/node]
4: 0x100585682 v8::internal::Heap::FatalProcessOutOfMemory(char const) [/usr/local/bin/node]
5: 0x100588155 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/bin/node]
6: 0x100583fff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
7: 0x1005821d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
8: 0x10058ea6c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
9: 0x10058eaef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
10: 0x10055de86 v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::Heap::RootListIndex, int, v8::internal::Object, v8::internal::PretenureFlag) [/usr/local/bin/node]
11: 0x1005052ae v8::internal::(anonymous namespace)::ElementsAccessorBase
12: 0x1007a06bf v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object*, v8::internal::Isolate) [/usr/local/bin/node]
13: 0x36dcf845be3d
[1] 1295 abort npm run build:dev```
Does anyone know if this is due to having just one gigantic module for an application? Our team ran into this issue and we have just 1 app module with 30+ routes and many components and i was curious if breaking the application down into smaller modules would help avoid the out of memory issue during source mapping?
Sourcemap processing is unfortunately highly memory intensive. Breaking a very large output bundle into smaller ones via lazy routes may not completely alleviate the issue but should definitely help mitigate it. It may also provide a benefit to end users of the application as well since less code needs to be downloaded and executed prior to first interaction.
Thanks @clydin. Im aware of the benefits and we plan to do it but was more curious if have still seen this with many modules as well? I presume each chunked module would get sourcemapped separately right?
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build client --prod
i have the save problem
Angular CLI 8.1.0
Node 10.16.3
NPM 6.9.0
Same issue here too:
@angular/cli: 8.3.3
node: v10.16.3
npm: 6.9.0
Physical memory: 32GB
Memory used: 18GB
The error:
Generating ES5 bundles for differential loading...
<--- Last few GCs --->
[98174:0x108000000] 35352 ms: Scavenge 1329.2 (1422.0) -> 1328.7 (1422.5) MB, 2.8 / 0.0 ms (average mu = 0.094, current mu = 0.035) allocation failure
[98174:0x108000000] 35355 ms: Scavenge 1329.4 (1422.5) -> 1328.9 (1423.0) MB, 2.9 / 0.0 ms (average mu = 0.094, current mu = 0.035) allocation failure
[98174:0x108000000] 35359 ms: Scavenge 1329.7 (1423.0) -> 1329.2 (1423.5) MB, 2.8 / 0.0 ms (average mu = 0.094, current mu = 0.035) allocation failure
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x31c8cd85be3d]
1: StubFrame [pc: 0x31c8cd85d3c6]
Security context: 0x1c2a4551e6e9 <JSObject>
2: SourceMapGenerator_serializeMappings [0x1c2a9a9ea811] [/Users/dmoore/projects/[project]/web/node_modules/@babel/generator/node_modules/source-map/lib/source-map-generator.js:~303] [pc=0x31c8cdfb72d2](this=0x1c2a31a02341 <SourceMapGenerator map = 0x1c2a82318309>)
3: SourceMapGenerator...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x10003b348 node::Abort() [/usr/local/Cellar/node@10/10.16.3/bin/node]
2: 0x10003b521 node::OnFatalError(char const*, char const*) [/usr/local/Cellar/node@10/10.16.3/bin/node]
3: 0x10017cbbf v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node@10/10.16.3/bin/node]
4: 0x10017cb60 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node@10/10.16.3/bin/node]
5: 0x1004328e4 v8::internal::Heap::UpdateSurvivalStatistics(int) [/usr/local/Cellar/node@10/10.16.3/bin/node]
6: 0x100434523 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/Cellar/node@10/10.16.3/bin/node]
7: 0x100431bbe v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/Cellar/node@10/10.16.3/bin/node]
8: 0x1004309dd v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/Cellar/node@10/10.16.3/bin/node]
This is why?
Why is this issue closed?
The error went away after upgrading to node v12.10.0
. Finally.
Just upgraded to node v12.10.0
and it didn't go away for us, unfortunately.
Ok Ths!
发自我的iPhone
------------------ Original ------------------
From: Kyle <[email protected]>
Date: Wed,Oct 2,2019 1:43 AM
To: angular/angular-cli <[email protected]>
Cc: zhangwk02 <[email protected]>, Comment <[email protected]>
Subject: Re: [angular/angular-cli] Build fails with JavaScript heap out of memory (#12645)
Just upgraded to node v12.10.0 and it didn't go away for us, unfortunately.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
I ran into this problem building an Angular project within a Docker container. I made sure to use current version of node (12.12), and I had to increase the RAM available to docker.
Here too. Working with Docker with 2GB RAM. It worked fine with node 10, but reaches the memory limit with node 12.
Had to deal with an ancient Jenkins server, so upgrading node wasn't really an option. Downgrading angular cli to 8.2.2 worked in this case. I suspect the out of memory error was caused by a change introduced in angular 8.3.x. The parallel bundle processing during ng build --prod
builds for both es2015 and es5 at the same time, thus the memory shortage.
Improve performance of parallel bundle processing [8.3.x]
Differential builds
In my case I'm using angular cli 7.3.9.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
allows build to complete, just need to know why my bundle has increase by 260kb