Skip to content

Build fails with JavaScript heap out of memory #12645

Closed
Closed
Build fails with JavaScript heap out of memory#12645

Description

@dottodot
dottodot
opened on Oct 19, 2018

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.

Activity

  1. filipesilva commented on Oct 19, 2018

    @filipesilva
    filipesilva
    on Oct 19, 2018
    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.

  2. filipesilva
    closed this as completedon Oct 19, 2018

  3. dottodot commented on Oct 19, 2018

    @dottodot
    dottodot
    on Oct 19, 2018
    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

  4. joachim-bl commented on Oct 23, 2018

    @joachim-bl
    joachim-bl
    on Oct 23, 2018

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

  5. kartik1195 commented on Mar 27, 2019

    @kartik1195
    kartik1195
    on Mar 27, 2019

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

  6. Dev-Pawar commented on Apr 12, 2019

    @Dev-Pawar
    Dev-Pawar
    on Apr 12, 2019

    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

  7. bharat-banavalikar commented on Apr 24, 2019

    @bharat-banavalikar
    bharat-banavalikar
    on Apr 24, 2019

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

  8. ramsunvtech commented on Aug 13, 2019

    @ramsunvtech
    ramsunvtech
    on Aug 13, 2019

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

  9. quincarter commented on Aug 30, 2019

    @quincarter
    quincarter
    on 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```

  10. janstadt commented on Sep 5, 2019

    @janstadt
    janstadt
    on 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?

  11. clydin commented on Sep 5, 2019

    @clydin
    clydin
    on Sep 5, 2019
    Member

    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.

  12. janstadt commented on Sep 5, 2019

    @janstadt
    janstadt
    on 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?

  13. renyuns commented on Sep 10, 2019

    @renyuns
    renyuns
    on 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

  14. demisx commented on Sep 25, 2019

    @demisx
    demisx
    on 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]

  15. zhangwk02 commented on Sep 26, 2019

    @zhangwk02
    zhangwk02
    on Sep 26, 2019

    This is why?

  16. denysvitali commented on Sep 26, 2019

    @denysvitali
    denysvitali
    on Sep 26, 2019

    Why is this issue closed?

  17. demisx commented on Sep 30, 2019

    @demisx
    demisx
    on Sep 30, 2019

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

  18. kbpontius commented on Oct 1, 2019

    @kbpontius
    kbpontius
    on Oct 1, 2019

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

  19. zhangwk02 commented on Oct 2, 2019

    @zhangwk02
    zhangwk02
    on Oct 2, 2019 via email

  20. dahovey commented on Oct 15, 2019

    @dahovey
    dahovey
    on 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.

  21. orgads commented on Oct 31, 2019

    @orgads
    orgads
    on 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.

  22. chenwenshu commented on Nov 4, 2019

    @chenwenshu
    chenwenshu
    on Nov 4, 2019

    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

  23. orgads commented on Nov 4, 2019

    @orgads
    orgads
    on Nov 4, 2019

    In my case I'm using angular cli 7.3.9.

  24. angular-automatic-lock-bot commented on Dec 5, 2019

    @angular-automatic-lock-bot
    angular-automatic-lock-botBot
    on Dec 5, 2019

    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.

  25. angular-automatic-lock-bot
    locked and limited conversation to collaborators on Dec 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions