AOT build fails due to "JavaScript heap out of memory"

[ghost]

Bug Report or Feature Request (mark with an x)

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

Versions.

@angular/cli: 1.0.0
node: 7.7.4
os: win32 x64
@angular/animations: 4.0.0
@angular/common: 4.0.0
@angular/compiler: 4.0.0
@angular/core: 4.0.0
@angular/flex-layout: 2.0.0-rc.1
@angular/forms: 4.0.0
@angular/http: 4.0.0
@angular/material: 2.0.0-beta.2
@angular/platform-browser: 4.0.0
@angular/platform-browser-dynamic: 4.0.0
@angular/router: 4.0.0
@angular/cli: 1.0.0
@angular/compiler-cli: 4.0.0

Repro steps.

ng build --prod --aot

The log given by the failure.

/node_modules/@angular/material/aut 92% chunk asset optimization
<--- Last few GCs --->

[6328:0000016AB4D09F00]  1775597 ms: Mark-sweep 1411.2 (1513.5) -> 1411.0 (1513.5) MB, 1240.6 / 0.0 ms  last resort

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000034B0DD266A1 <JS Object>
    2: optimize [0000000FABC02311 <undefined>:5480] [pc=00000082575652C8](this=000000633199A279 <an AST_Call with map 0000014753FA0291>,compressor=00000226DBDECA61 <a Compressor with map 0000032B1EC8F829>)
    3: before [0000000FABC02311 <undefined>:5463] [pc=0000008258C1818D](this=00000226DBDECA61 <a Compressor with map 0000032B1EC8F829>,node=000000633199A279 <an AST_Call with map 0000014753...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Desired functionality.

I would like to be able the app using AOT.

Mention any other details that might be useful.

I have tried changing ng.cmd to this:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe" --max_old_space_size=8192 "%~dp0\..\@angular\cli\bin\ng" %*
) ELSE (
  @SETLOCAL
  @SET PATHEXT=%PATHEXT:;.JS;=;%
  node --max_old_space_size=8192 "%~dp0\..\@angular\cli\bin\ng" %*
)

and ngc.cmd to:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe" --max_old_space_size=8192 "%~dp0\..\@angular\compiler-cli\src\main.js" %*
) ELSE (
  @SETLOCAL
  @SET PATHEXT=%PATHEXT:;.JS;=;%
  node --max_old_space_size=8192 "%~dp0\..\@angular\compiler-cli\src\main.js" %*
)

I have 8GB swap file. The build fails after 20-25 minutes standing on 92% progress.

[wojciech-wator]

Also got this error.

Locking @ngtools/webpack to version 1.5.4 helps.

[josephliccini]

I had to increase memory given to Node, as well as bump TS to 2.4.2, but after that I did get a successful build. looking forward to NG5 AoT compiler

[williangd]

Same problem here after updating to @angular/cli 1.3.0.

[ChenReuven]

@williangd also for me with 1.3.0

[jloosli]

I've also been getting the out of memory issue when running ng serve. It works fine for hours, but if I've been developing for a while (I've seen it anywhere from 2-5 hours) I will get the out of memory crash. When rerunning the serve command, I can go typically for another 2-5 hours. The first time I saw this was when updating to a beta version of 1.3, but I haven't seen an improvement with the current release.

[Dunos]

For me it also happens with the normal "ng serve" after upgrading to 1.3 version, every time the project recompiles, its takes more time than the previous (6s, 10s, 30s, 60s) and after 4 or 5 times, it goes out of memory.

[AlekBro]

Same issue.

95% emitting <--- Last few GCs --->

160332 ms: Mark-sweep 1346.8 (1439.3) -> 1346.7 (1439.3) MB, 648.6 / 0.0 ms [allocation failure] [scavenge might not succeed]. 160934 ms: Mark-sweep 1346.7 (1439.3) -> 1346.8 (1439.3) MB, 602.0 / 0.0 ms [allocation failure] [scavenge might not succeed]. 161564 ms: Mark-sweep 1346.8 (1439.3) -> 1346.8 (1423.3) MB, 629.5 / 0.0 ms [last resort gc]. 162181 ms: Mark-sweep 1346.8 (1423.3) -> 1346.7 (1423.3) MB, 616.9 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000009DB903FA99 1: DoJoin(aka DoJoin) [native array.js:~129] [pc=000000A40AE7FE82] (this=0000009DB9004241 ,w=00000355FBAF7F99 <JS Array[287]>,x=287,N=0000009DB9004281 ,J=0 000009DB904A369 <String[1]: >,I=00000342545B4E81 <JS Function ConvertToString (SharedFunctionInfo 0000009DB905DBC9)>) 2: Join(aka Join) [native array.js:180] [pc=000000A406C83FF2] (this=0000009DB9004241 ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

tsc -v Version 2.4.2

@angular/cli: 1.3.0 node: 6.11.2 os: win32 x64

[sbabeal]

How is upgrading to typescript 2.4.2 working. You will get build issues from RxJs as they 2.4 broke the typings of rxjs

[sbabeal]

This problem is happening as well for our project. Can't build aot on build server with the same javascript heap out of memory. We are also using the experimental webpack 3 support.

[josephliccini]

@sbabeal just go to RxJS 5.4.2

[chriseenberg]

For us - building locally with ng build --target=production --environment=prod --base-href /myproject/ --aot --build-optimizer works just fine, but when we build it on our server, we get the FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory error. However, if we remove the --build-optimizer everything runs fine.

I've tried adding the increase-memory-limit library, but without any luck.

Is there a fix to this that actually works?

Kind regards Chris

[sbabeal]

Tried latest version of typescript and still didn't help. Locally it builds but consumes 1.5 gigs of memory. Seems quite excessive.

[phamtuananh791994]

92% chunk asset optimization <--- Last few GCs --->

[3933:0x2a7d710] 355436 ms: Mark-sweep 1395.8 (1546.4) -> 1395.3 (1546.4) MB, 975.3 / 0.0 ms allocation failure GC in old space requested [3933:0x2a7d710] 356584 ms: Mark-sweep 1395.3 (1546.4) -> 1395.3 (1546.9) MB, 976.0 / 0.0 ms allocation failure GC in old space requested [3933:0x2a7d710] 357953 ms: Mark-sweep 1395.3 (1546.9) -> 1395.3 (1539.9) MB, 1195.7 / 0.0 ms last resort [3933:0x2a7d710] 359143 ms: Mark-sweep 1395.3 (1539.9) -> 1395.3 (1539.9) MB, 1188.8 / 0.0 ms last resort

<--- JS stacktrace --->

==== JS stack trace =========================================

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory 1: node::Abort() [@angular/cli] 2: 0x12b717c [@angular/cli] 3: v8::Utils::ReportOOMFailure(char const, bool) [@angular/cli] 4: v8::internal::V8::FatalProcessOutOfMemory(char const, bool) [@angular/cli] 5: v8::internal::Factory::NewCode(v8::internal::CodeDesc const&, unsigned int, v8::internal::Handle, bool, bool, int, bool) [@angular/cli] 6: v8::internal::CodeGenerator::MakeCodeEpilogue(v8::internal::MacroAssembler, v8::internal::EhFrameWriter, v8::internal::CompilationInfo, v8::internal::Handle) [@angular/cli] 7: v8::internal::FullCodeGenerator::MakeCode(v8::internal::CompilationInfo, unsigned long) [@angular/cli] 8: v8::internal::FullCodegenCompilationJob::ExecuteJobImpl() [@angular/cli] 9: v8::internal::CompilationJob::ExecuteJob() [@angular/cli] 10: 0xd577dc [@angular/cli] 11: 0xd59faa [@angular/cli] 12: 0xd5b7a9 [@angular/cli] 13: v8::internal::Compiler::Compile(v8::internal::Handle, v8::internal::Compiler::ClearExceptionFlag) [@angular/cli] 14: v8::internal::Runtime_CompileLazy(int, v8::internal::Object*, v8::internal::Isolate) [@angular/cli] 15: 0x3e6ef29040c7 Aborted (core dumped)

[linkevin777]

We seem to face the error even on allocating 12GB of memory for the build. Is there any way to debug what is causing the memory leak? also, could this be solved by implementing lazy loading of modules, since this is during build time?

Commands used: 1.node --max_old_space_size=12000 ./node_modules/@angular/cli/bin/ng build --prod --aot --env=prod

2. updated the ng to accept the --max_old_space_size parameter

The build is working only with --sourcemap=false and --aot=false; but this is causing memory leaks and page load issues in the browser due to huge application size.

StackTrace:- [INFO] [INFO] <--- Last few GCs ---> [INFO] [INFO] [11944:0x2710b70] 898052 ms: Mark-sweep 11998.2 (13529.5) -> 11998.2 (13529.5) MB, 4991.9 / 0.0 ms allocation failure GC in old space requested [INFO] [11944:0x2710b70] 903445 ms: Mark-sweep 11998.2 (13529.5) -> 11998.1 (13434.0) MB, 5366.9 / 0.0 ms last resort [INFO] [11944:0x2710b70] 908749 ms: Mark-sweep 11998.1 (13434.0) -> 11998.1 (13378.0) MB, 5266.9 / 0.0 ms last resort [INFO] [INFO] [INFO] <--- JS stacktrace ---> [INFO] [INFO] ==== JS stack trace ========================================= [INFO] [INFO] Security context: 0x2b8a8b3a66a1 [INFO] 1: DoJoin(aka DoJoin) [native array.js:~97] [pc=0x168f8ea1398a](this=0x38d692102311 ,q=0x39d30737fbe1 <JS Array[2905]>,r=2905,F=0x38d6921023b1 ,B=0x38d692157ff9 <String[1]: >,A=0x38d692102421 )

[INFO]

[loic49]

I don't know if it can help someone but we had the same problem after upgrading to version 1.3.0. And we had others problem too : slow compilation and bad names for generated chunk.

All our problems were solved with this : https://github.com/angular/angular-cli/pull/7338

[ghost]

FTR, for one project, we abandoned Angular because of this. No amount of --max_old_space_size helps anymore.

Great work alienating enterprise users.

[Masquer]

There's always an option to eject the app.

[linkevin777]

What do you mean by ejecting the application?

On Tue, Aug 22, 2017 at 5:12 PM, Arseny E. Naryshkin < notifications@github.com> wrote:

There's always an option to eject the app.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/angular/angular-cli/issues/5618#issuecomment-324021572, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuwsXkLSkoHTg9-AMuUESUfM2sCLVbOks5satPRgaJpZM4Mn-Nn .

[randyaa]

Still a problem for us even after CLI upgrade to 1.3.1 and @angular upgrade to 4.3.5

tried typescript 2.5 but run into some compilation problems. we're on 2.4.2.

edited:

On our local machines or our gitlab runner instances we can't reproduce the problem. For some reason the build only fails on our jenkins box. The only difference I've been able to gather is jenkins is on a slightly older version of node/npm version:

v6.9.1
3.10.8

instead of

v6.11.0
3.10.10

fixed by changing our production npm build script to:

"build-prod": "node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng build --prod --aot",

Not so much a fix as it is a brute force work-around, but it'll at least buy time while we figure out what's eating up all the heap space.

[ghost]

@Masquer how would eject help? It's actually a webpack problem.

[Masquer]

@notsonotso oh, it will not then.

my app, however, fails to compile by ng with 'heap out of memory' error, but does as ejected.

[mgechev]

Here's a related, solved issue in angular-seed. I hope it helps someone.

[mattem]

No amount of setting max-old-space-size helped on our project. However, as we only build AOT in prod, we have temporarily disabled sourcemaps which seemed to fix it for us on our CI server.

[timwright35]

Like @mattem I have not been able to get the max-old-space-size to work either. I do not if I am fully setting it up right though since the build process I have uses webpack with "ngtools/webpack".

[bgever]

Same issue, but we've found a more reliable workaround to increase the memory limit.

Since Node 8.x, you can set a NODE_OPTIONS environment variable, and pass in the --old-max-space-size flag. We currently need 6GB.

E.g. on Windows CMD: set NODE_OPTIONS=--old-max-space-size=6411 before running the AOT build.

I wonder if there is a child process that doesn't get the arguments that are set on the node executable.

[bgever]

I know, and trust me, I'm just as much struggling with this. Not fun when the build server starts to run out of memory. It's a serious problem that should be addressed. This workaround just helped me to limp along a little farther, just like turning off the source maps. Your mileage may vary.

[Tolitech]

Hello. this problem is serious.

On my computer I was limiting to 8Gb and the ng build was working fine. (with old-max-space-size)

But now I've got a big big project and believe me, out of memory.

I have a code generator that builds everything perfectly. but the new project has more than 200 entities. The creation of modules and lazy loading depends on the settings made by the client and their entities.

I would not want to separate in several applications because there is a lot of dependency. (200 services, 600 components)

The project runs fine with ng serve, but not with ng build. I rented a virtual machine with 28Gb ram and believe me, did the build using 27Gb of RAM. The service node occupied exactly 27Gb.

(I put the limit of 28gb)

Everything works fine with ng serve.

can anyone know to tell me if just separating into several lazy loading modules it will need less memory to compile with ng build? or it works only to separate the JS?

I can not rent a virtual machine whenever I need to run ng build. And the effort of change will be very high. So I needed to be sure of what to do.

Thanks.

[joecot]

@Tolitech Instead of depending on having enough RAM for this to build, just add swap to your machine. The build will be a little slower, but you don't need to be renting machines with 28 GB of RAM.

I too want this to be resolved ASAP, but adding swap space gets around the memory issue.

[Tolitech]

@joecot Thank you. I'll try to do this and see if it works. If it works, I do not see any problems if it takes 8 hours. I leave a night job for publication without problems.

That was a good idea. I'll try.

Thank you.

[Tolitech]

@joecot @notsonotso It worked. I configured 32Gb virtual memory (swap), --max_old_space_size and finally worked. It used the 28gb (It's too high), but it worked. Thank you very much for the idea, @joecot

[bgever]

@mhevery @bradlygreen - apologies for pulling you into this one, but with @Tolitech's extreme case above, the value proposition of Angular is starting to become seriously undermined.

Our codebase is growing rapidly, and our team is continuously running into these memory issues, where we even reach the limitations of our development and build machines. In all my years of web development there's never been a case that I would run out of the capabilities of the machine, just to compile to several 300k files for my webapp/website. It seems to be a memory optimization or architectural issue that hopefully can be avoided.

We've already lost countless hours on these problems, and the premise that Angular is a framework that scales for large enterprise applications doesn't hold up anymore.

I'd really appreciate if this issue could be prioritized, as I'm really starting to doubt whether our choice of Angular as a suitable framework was correct, considering that only the AOT builds are performant and small enough to ship to customers over the wire, and that we're struggling to get those to work. Thank you.

[xnnkmd]

@bgever Apparently google is not using angular-cli/webpack themselves, so they don't run into problems like this. I suspect this is why this problem receives so little attention from the angular developers. If this continues, the community should be publicly warned about angular being unsuitable for large projects.

[Tolitech]

You were perfect in your words, @bgever . I'm already thinking that Angular does not work for large applications, after all I'm now needing 28 Gb of RAM and the project could grow bigger. (This is the first day of this application).

I'm already thinking about another strategy for this type of project, maybe even change technology because I'm realizing that this problem is occurring with many people and for a long time.

I believe my customer will not accept me saying that he needs 28 Gb RAM to compile his own project. I'm very worried about this.

[Dunos]

I'm just staying in Angular CLI 1.2.7 while they fix this, hope they do it soon tho, but with 1.2.7 I have no memory problems at all.

[bjornharvold]

Same here. Running Angular CLI 1.3.2 and Angular 4.3.6. Added this based on another thread to get it to work. My app isn't very big but CLI clocked in at 4GB to build my app.

"scripts": {
    "build": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --target production --environment prod --aot",
    "ng": "ng",
    "start": "ng serve",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

[elvisbegovic]

@bjornharvold @Tolitech We need 1024go ram 32ghz cpu, so 32'000'000'000 calcul per second to build angular but if you learn bazel from google it can be faster 😂

[gtarun]

https://github.com/endel/increase-memory-limit

This worked for me

[hugodes]

Same problem here.

I had to downgrade to @angular/cli 1.2.6 with TS 2.4.2 for the build to work again.

A shame I can't use the latest angular cli ... Why isn't this considered a severe bug ?

[alexzuza]

@hugodes

Why isn't this considered a severe bug ?

I think it is because of https://github.com/angular/angular/issues/19058

[phamtuananh791994]

Lastest version is the same !

[DutchKevv]

Same here, this is ridiculous. I'm using a cheap VPS server to build and it simply crashes with 2GB of memory

[hugodes]

What solved it for me was doing ng build --prod instead of ng build --aot --prod.

The --prod option already includes the --aot one, and optimises the build process and I'm not getting memory errors any more.

Hope it helps some of you guys.

[aminebizid]

Try -sm false

[jota0222]

It happens to me when the allowJS parameter is true in tsconfig.json. Apparently, the javascript files are overloading the memory.

[clevagroup]

This worked for me, add to package.json scripts section. Watching the memory usage in task manager it got up to around 4gb usage. Seems a touch excessive!

"build2": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --prod --aot"

npm run build2

[tupham]

This command works for me: node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build --prod

"scripts":{ "prod": "node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build --prod" }

[tossp]

try process.nextTick() ？

[marcalj]

With Node 8.x and latest cli version works without any hack :)

[andremarcondesteixeira]

Sad to see that months have passed and this issue is still not solved. I'm having the same problem here:

´ ng build --aot

92% chunk asset optimization <--- Last few GCs --->

191455 ms: Mark-sweep 1296.7 (1433.7) -> 1291.4 (1434.7) MB, 1052.3 / 0.0 ms [allocation failure] [GC in old space request ed]. 192605 ms: Mark-sweep 1291.4 (1434.7) -> 1291.4 (1434.7) MB, 1150.6 / 0.0 ms [allocation failure] [GC in old space request ed]. 193711 ms: Mark-sweep 1291.4 (1434.7) -> 1294.8 (1403.7) MB, 1105.0 / 0.0 ms [last resort gc]. 194808 ms: Mark-sweep 1294.8 (1403.7) -> 1298.3 (1403.7) MB, 1097.0 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 00000146E3DCF791 2: addMapping(aka SourceMapGenerator_addMapping) [D:\Users \andre.marcondes\projects\lender-platform\node_modules\source- map\lib\source-map-generator.js:~94] [pc=00000339B436339E] (th is=0000015776039641 <a SourceMapGenerator with map 00000102C1F AA599>,aArgs=00000004C17F22D1 <an Object with map 00000194E061 0DD9>) 3: / anonymous / [D:\Users\andre.marcondes\projects\lend er-platform\node...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScrip t heap out of memory ´

[ghost]

I think this issue can be closed. Not because it's fixed, but because it will NOT be fixed. Not ever.

Google is busy trying to get a Bazel-based build system in place for public consumption, and they are unlikely to spend time fixing this old crap (it's mostly webpack's fault anyway)