Endless memory allocation until crash after a recompile during ng serve - started with version 8.2

[ncrawlins]

🐞 Bug report

Command (mark with an x)

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

Is this a regression?

Yes, the previous version in which this bug was not present was: 8.1.3

Description

When using ng serve or build --watch, when I make a change and it recompiles, it starts endlessly consuming memory until it crashes. A few seconds of the task manager are captured in this gif.

it just keeps allocating memory until it uses it all and crashes.

🔬 Minimal Reproduction

For me all I have to do is run ng serve and then make a change anywhere so that it recompiles. that triggers the endless loop of memory allocation.

For a minimal repro, I would appreciate some advice. I tried just doing this with a "hello world" app and the problem is not there (obviously that would have been caught), so it's something about my application's structure or additional libraries or something that confuses the 8.2 compiler.

While the app is not huge, it's not trivial, and I can't make it public on github. I don't really know where to begin to try to pare it down. and just reverting to 8.1.3 of the cli removes the issue. Is there any way to maybe turn on a debug log or something of that nature so I could provide info on what the cli is doing when it consumes all that memory? I turned on --verbose, but the output doesn't look significantly different than 8.1.3 and it doesn't continue to output anything once the incremental compile is done even though the memory use is continuing to grow.

Otherwise, I guess I can start chopping bits out and see if there is something obvious that makes the problem go away.

🔥 Exception or Error

#
# Fatal error in , line 0
# Fatal process out of memory: Zone
#
#
#
#FailureMessage Object: 00000024574F9F00

🌍 Your Environment

Angular CLI: 8.2.1
Node: 12.6.0
OS: win32 x64
Angular: 8.2.1
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router, service-worker

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.802.1
@angular-devkit/build-angular      0.802.1
@angular-devkit/build-optimizer    0.802.1
@angular-devkit/build-webpack      0.802.1
@angular-devkit/core               8.2.1
@angular-devkit/schematics         8.2.1
@angular/cdk                       8.1.2
@angular/material                  8.1.2
@angular/material-moment-adapter   8.1.2
@angular/pwa                       0.802.1
@ngtools/webpack                   8.2.1
@schematics/angular                8.2.1
@schematics/update                 0.802.1
rxjs                               6.5.2
typescript                         3.5.3
webpack                            4.38.0

Anything else relevant?

[filipesilva]

Heya, thanks for reaching out on this. We have a couple of ways to move forward. If you can share a private repo with me, I can take a look myself. If that's not an option, maybe we could set up a video call and do some debugging together. Another thing you can do is try to narrow down the problematic versions. A last option is profiling with Chrome Devtools, but it doesn't work very well at those high memory usage numbers.

I'm particularly keen on the first and third option because they are async and don't need a lot of synchronization. If you want to try the third option (narrow down version), then the right thing to alter is @angular-devkit/build-angular, because that's the build system proper.

If you do npm info @angular-devkit/build-angular versions you'll see all versions:

  ...
  '0.801.0',
  '0.801.1',
  '0.801.2',
  '0.801.3',
  '0.802.0-next.0',
  '0.802.0-next.1',
  '0.802.0-rc.0',
  '0.802.0',
  '0.802.1',
  '0.803.0-next.0',
  '0.803.0-next.1'

We have a naming scheme to match the versions for that package to @angular/cli versions. @angular-devkit/[email protected] matches @angular/[email protected]. So trying versions between 0.801.3 and 0.802.1 you should be able to find the first release that has the regression.

[ncrawlins]

it starts happening with 0.802.0-rc.0

[clydin]

Can you try the builds using 8.2.1 with TypeScript versions 3.3 and 3.4?

[filipesilva]

Ok that's great info, between those two releases we had a relatively small amount of commits: 50b290e...168f07e

If I had to bet, it would be caused by one of these three:

• build: update to TS 3.5 e8dff57
• fix(@angular-devkit/build-optimizer): don't wrap enum like nodes whic… ab80209
• fix(@ngtools/webpack): find aliased lazy route factories 0f8b332

It's not super clear to me which one though.

The third commit is the easiest to write off. It should only do something if you have lazy routes declared as import('./shared').then(m => m.LazyModule) where ./shared doesn't contain a NgModule, but rather a re-rexport. Do you have any of those? If so, can you try using the full path to it instead?

The second commit should only do anything if you're using Build Optimizer. You mention this happens on ng serve, which usually isn't used with Build Optimizer turned on. But just to double check, do you still get this when you use ng serve --build-optimizer false?

The first commit is harder to debug. TS 3.5 is used throughout the build system. We could probably copy over the contents of an older TS version directly onto node_modules but this is error prone so let's leave this option for last.

[ncrawlins]

It seems to be a problem with lazy routing modules. There were a bunch that were being loaded the pre v8 way with just a string. When I changed them to the dynamic import, the problem no longer seems to happen with current versions of everything.

[filipesilva]

I didn't expect #15189 to make any difference regarding that though. It should only kick-in on the new style of lazy imports... let's keep this issue open for a while to see if someone else runs into it and can provide a repro.

[filipesilva]

It looks like we haven't had other similar reports so far, so I guess it didn't affect a lot of people or that they were able to figure out how to move forward. I'll close this then.

[angular-automatic-lock-bot]

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