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

Build fails with JavaScript heap out of memory #12645

Closed
dottodot opened this issue Oct 19, 2018 · 23 comments
Closed

Build fails with JavaScript heap out of memory #12645

dottodot opened this issue Oct 19, 2018 · 23 comments

Comments

@dottodot
Copy link

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Command (mark with an x)

- [ ] new
- [x] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Versions

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

Package Version

@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

Repro steps

run ng build client --prod

The log given by the failure

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".

Desired functionality

v6 doesn't have any issue building the same app.

Mention any other details that might be useful

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.

@filipesilva
Copy link
Contributor

I think the difference between v6 and v7 is the bug reported in #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 #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 #5618 (comment).

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 #12646.

@dottodot
Copy link
Author

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

@joachim-bl
Copy link

The same exact behaviour here. And the same solution worked...thank you dottodot!

@kartik1195
Copy link

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" %*
)

@Dev-Pawar
Copy link

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

@bharat-banavalikar
Copy link

increase maximum memory allocated in angular.json
"budgets": [
{
"type": "initial",
"maximumWarning": "2mb",
"maximumError": "11mb"
}
]

@ramsunvtech
Copy link

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.

Syntax

node --max-old-space-size=<size> path-to/fileName.js

Example

node --max-old-space-size=16000 scripts/build.js

Why size is 16000 in max-old-space-size?

Basically, it varies depends on the allocated memory to that thread as per your node settings.

How to verify and give right size?

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);

@quincarter
Copy link

quincarter commented Aug 30, 2019

I am facing a similar issue on our app as well.

Angular 8.1.2


 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 <JSObject>
    1: /* anonymous */ [0x1648cd39f4a9] [...node_modules/webpack-sources/node_modules/source-map/lib/source-node.js:~342] [pc=0x36dcfb1746f2](this=0x1648ed98d481 <JSGlobal Object>,chunk=0x164838934a61 <String[1]\: \n>,original=0x1648900d57e1 <Object map = 0x164800b75d19>)
    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<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]
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```

@janstadt
Copy link

janstadt commented Sep 5, 2019

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?

@clydin
Copy link
Member

clydin commented Sep 5, 2019

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.

@janstadt
Copy link

janstadt commented Sep 5, 2019

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?

@renyuns
Copy link

renyuns commented Sep 10, 2019

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

@demisx
Copy link

demisx commented Sep 25, 2019

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]

@zhangwk02
Copy link

This is why?

@denysvitali
Copy link

Why is this issue closed?

@demisx
Copy link

demisx commented Sep 30, 2019

The error went away after upgrading to node v12.10.0. Finally.

@kbpontius
Copy link

Just upgraded to node v12.10.0 and it didn't go away for us, unfortunately.

@zhangwk02
Copy link

zhangwk02 commented Oct 2, 2019 via email

@dahovey
Copy link

dahovey commented Oct 15, 2019

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.

@orgads
Copy link

orgads commented Oct 31, 2019

Here too. Working with Docker with 2GB RAM. It worked fine with node 10, but reaches the memory limit with node 12.

@chenwenshu
Copy link

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

@orgads
Copy link

orgads commented Nov 4, 2019

In my case I'm using angular cli 7.3.9.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Dec 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests