Angular: Browser Memory isn't released when destroying components

[rmullins9]

I'm submitting a ... (check one with "x")

[X] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When triggering ComponentRef.destroy(), no browser memory is ever released. Any injected dependencies are all still there and running, even though the component is gone.

Also:
When bootstrapping an app within an iframe, destroying that app and removing the iframe from the DOM does not release browser memory.

In both of these scenarios, browser memory builds up over time and the browser tab and angular app lock up or crash. Injected dependencies are created, but never removed.

Expected behavior

Browser memory should be released as apps and components are destroyed.

Minimal reproduction of the problem with instructions

STEPS TO REPRODUCE

REPRODUCING DEPENDENCY LEAK
1) Run the Tour of Heroes plnkr in Chrome or IE
https://plnkr.co/edit/R9axXVtjep5VO8hWygpA?p=preview

2) Open the js console and watch the logging in the hero service, which does not stop after destroying the app.

• Note, this is the Tour of Heroes example, except that after the app is bootstrapped in main.ts, I've added a 15sec timer that runs ref.destroy(). Additionally, in the hero.service.ts file, I added a console log in the constructor that prints every second. You can see that the service continues to run even after triggering .destroy() on the component ref.

REPRODUCING IFRAME LEAK

1. Run the Tour of Heroes live example in IE 11
   https://angular.io/resources/live-examples/toh-6/ts/eplnkr.html

1. Open F12 dev tools, click on Memory and click "Start profiling to begin a performance session"

2. Make changes to the files by adding line breaks. Every time the app reloads in the iframe the memory will grow. After about 15 minutes of this the app will lock up due to the IE tab hitting the 1.5Gb memory limit. If you test with app that has more dependencies, it will lock up much faster.

This can be reproduced in Chrome too, it just takes longer for the memory leak to build up that much.

What is the motivation / use case for changing the behavior?

Large-scale angular apps that use iframes or rely on destroying components will leak memory over time and eventually crash or lock up.

Please tell us about your environment:

Mac OS 10.11.6

• Angular version: 2.0.X
  
  Angular v2.4.1
• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  
  all
• Language: [all | TypeScript X.X | ES6/7 | ES5]
  all
• Node (for AoT issues): node --version =

[wKoza]

For information, there is a bug in IE related here : https://connect.microsoft.com/IE/Feedback/Details/1742276

I had this problem at my work.

[DzmitryShylovich]

@rmullins9 can u pls add a github repo with reproduction? Plunkr contains a lot of additional script besides the angular app.

[rmullins9]

@wKoza - Yes I think it's possible that IE bug plays a role in the iframe issue. It still looks like angular isn't cleaning up the injector or dependencies on destroy() though. @DzmitryShylovich - i'll get something together shortly and post back - I still think your original post might be right, that it's related to the router also not being destroyed. Thank you both!

[DzmitryShylovich]

@rmullins9 can you try it out in a prod mode?

[rmullins9]

Hey @DzmitryShylovich - sorry for the delay. Yes I tried in prod mode with the same results. I did more research on this an put together quick demo repo based partially on @talsi 's (https://github.com/talsi/ng2-bug-reproduce-destroy)
https://github.com/rmullins9/angular2-service-destruction

Basically what I found is that if a service class has any properties, the memory allocated for those variables will never be released, even after calling destroy() on the component ref and platform ref. When the GC runs, none of that memory is released either.

Take the HeroTaxReturnService for example:
https://angular.io/docs/ts/latest/guide/hierarchical-dependency-injection.html
@Injectable()
export class HeroTaxReturnService {
private currentTaxReturn: HeroTaxReturn;
private originalTaxReturn: HeroTaxReturn;
constructor(private heroService: HeroesService) { }

.. Any memory that the browser allocates for the currentTaxReturn and originalTaxReturn variables will never be released by the garbage collector at any point until the browser tab is closed.

[mcgraphix]

After destroying the app and platform, its seems that there are references to the AppModule stored on the window. From what I can tell (and I'm not expert in tracking down memory leaks) there seem to be some methods related to Testability added to the window. I'm curious if those are storing handles to the application modules which might prevent the memory from being freed. Either way, this is still a huge problem because I need to be able to load several apps into a portal on demand so multiple angular apps need to be bootstrapped into the same page and right now, this issue prevents that from being feasible.

[DzmitryShylovich]

its seems that there are references to the AppModule stored on the window

even with enabled prod mode? have you tried 4.0?

[mcgraphix]

I tried with enableProdMode. I have not tried version 4 yet though. I'm using angular cli. Is there a way to make that use version 4 yet?

[DzmitryShylovich]

you can generate a new project using --ng4 flag or you can just update dependencies and typescript version in package.json

[mcgraphix]

ok. I'll try that. Its EOD for me here so I will have to try it later tonight or in the morning.

[mcgraphix]

Ok. I tried with v 4.0.0 RC 1 and I see the same issue. I uploaded the bare-bones app at https://github.com/mcgraphix/angular-destroy-bug
If you run that application using ng serve, and click the destroy button it will call destroy() on both the platform returned from platformBrowserDynamic() and destroy() on the NgModuleRef that which the bootstrap promise resolves with. After calling destroy the app goes away and the app-root node is removed from the dom. However, calling window.getAllAngularRootElements() returns a reference to it. So I would hypothesize that the Testability API is causing memory leaks by not releasing its references. Let alone that the Testability seems to add methods on window. I haven't tested it, but based on the code it looks like if you were to load two apps on the page, the second one would overwrite the first one. And in no case are those methods ever removed which seems bad IMHO.

[DzmitryShylovich]

@mcgraphix yeah, you are right. I'll submit a fix.

[DzmitryShylovich]

calling window.getAllAngularRootElements() returns a reference to it. So I would hypothesize that the Testability API is causing memory leaks by not releasing its references.

I fixed this.

you were to load two apps on the page, the second one would overwrite the first one. And in no case are those methods ever removed which seems bad

but this is slightly harder to fix. Need to introduce some kind of app id.

[mcgraphix]

Thanks for taking a look so quickly. Is there a way via some provider to turn off the whole testability registration? I see that there is _NoopTestabilityGetter which doesn't look like it adds anything to the window. How would one go about using that? If that could be done, at least it would be a work around in production for now.

[DzmitryShylovich]

if enableProdMode doesn't disable it then no

[mcgraphix]

It doesn't. It looks like BrowserGetTestability has a static init() method that creates an instance of the BrowserGetTestability and sets that using setTestabilityGetter(). That init method gets called from initDomAdapter() method from browser.ts. I would expect that enableProdMode would be the right place to turn that off. I may try to just hack the compiled JS file to not call that init method to see if that solves the issue. Though it may not have any effect without your fix for the TestabilityRegistry. Forgive me... I am new to this kind of thing, but is there a way I can merge your change and rebuild Angular 4 locally to test your fix without waiting for it be merged for real?

[DzmitryShylovich]

I think it will be easier to change already compiled js file inside node modules if you need it asap. it's just a 1 LOC

[mcgraphix]

I can try that. Is it just a matter of adding this:

TestabilityRegistry.prototype.ngOnDestroy = function() {this._applications.clear();};

[mcgraphix]

I did a little more digging on this last night and this morning. It seems that ngOnDestroy of the TestabilityRegistry doesn't get called when calling destroy() on the NgModuleRef or the platform. So I make a couple of "hacks". First I commented out the contents of the setTestabilityGetter function such that the BrowserGetTestability is not used. second, in the addToWindow of the NoopGetTestability, I store it on the window so that I can manually access it to call ngOnDestory. Calling it manually (and then removing the reference to it on the window) helps reduce the memory usage. You can see after calling that that there are no references to AppModule when you take a JS heap snapshot. However, even after that, you can still see references to ApplicationRef, NgControl, and AppView in both the window.webpackJsonp and window.assert. If you delete both of those off the window the heap snapshot no longer has any references to any of those object and memory is reduced by about 4 megabytes.

[DzmitryShylovich]

@mcgraphix can you add the plunkr that reproduces the issue?

[mcgraphix]

sure. I not sure how much Plunkr's own memory usage will cloud the issue though.

[mcgraphix]

Here is plunkr showing the issue as it stands in 2.x. https://plnkr.co/edit/2O7Tzrt14b6LxRhooeuK?p=preview

If you press the Log Info button it will output to the console the result of calling getAllAngularRootElements() and getAngularTestability(getAllAngularRootElements()[0]. Clicking the destroy button destroys both the NgModuleRef and the platform as I stated above. Once you to that, clicking the Log Info button will still return references correctly. If you take a JS Heap Snapshot you will see that there are still references to AppModule, AppModuleInjector, AppView, NgControl, NgZone, NgModuleResolver, etc. Some of this might be expected since you could technically want to bootstrap the app again so those might be ok. However, there are a lot of detached DOM nodes

I don't know how to get plunkr to use v4 though.

However I was able to "hack" a solution to all the issues by doing several things in my local build. Firstly, I concatenate all the JS bundle files into one JS file and wrap all of it into a closure. I add a MutationObserver on the node that the app-root is in so I can know when that node is removed. In my case, that happens when the portal navigates to another application. In the handler for that observer, I call destroy on the NgModuleRef, the platform and the router. I then delete window.assert and window.webpackJsonp. I then need to manually call the ngOnDestroy method of the TestabilityRegistry because it doesn't seem to get called automatically. I also, had to hack in some code so that the BrowserGetTestability isn't used and the Noop one is.

With all of that I am able to reclaim almost all of the memory of the application. I'm sure my case is not the core use case for Angular so I'm not sure how urgent this is for others, but for us at ADP, this is make or break issue.

[DzmitryShylovich]

I don't know how to get plunkr to use v4 though.

update config.js http://plnkr.co/edit/lU32vBJY9KYXZUTW7GQQ?p=preview

[DzmitryShylovich]

@mcgraphix you can try this fix https://github.com/angular/angular/pull/14819

[mischkl]

This bug is preventing us from using ag-grid with NG4. Please fix it ASAP! :)

[benetis-bentley]

While we are waiting for this to be merged - I was wondering are there any workarounds without editing node_modules code. Like not using something?

[tbosch]

Hi, could someone confirm that this fix is actually working for you?

On May 8, 2017 2:37 AM, "benetis-bentley" [e-mail] wrote:

While we are waiting for this to be merged - I was wondering are there any
workarounds without editing node_modules code. Like not using something?

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular/issues/13725#issuecomment-299820295,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqKfypTvbkFofyxb8n5TXl8gN1Mxj5Iks5r3uJ0gaJpZM4LYXyb
.

[benetis-bentley]

Actually it didn't fix my problem (only tried to add one liner from comments up). Was hoping that I am missing something else and PR would fix it. Now coming to conclusion that this isn't related to leak problems l am encountering. After catching subscriptions which were not unsubscribed i stopped seeing anything related to this issue

[mischkl]

Any news on this front? Experienced a memory leak in my own code today that only occurs when enableProdMode() is turned on. It turned out using changeDetection: OnPush in one of our components managed to fix the problem, although that seems really odd. With default change detection, the memory quickly went through the roof and the application became unresponsive after about 1 minute and 1GB memory usage (using Chrome). Could it be that this has to do with this bug?

[mcgraphix]

I had originally came up with a workaround (aka hack) to fix this in Angular 2.x. However, it doesn't work in Angular 4. The issue seems to be that calling appModule.destroy() doesn't remove everything from memory. Specifically, I can see that subscribers to the router.events observable continue to receive values even after both the router and appModule have been destroyed. This is a MAJOR PROBLEM for apps that are being integrated into a portal environment. The original fix by @DzmitryShylovich doesn't seem like it was ever merged.

[noahvans]

Since our customer reported that our new software version often makes Chrome no responsing, we found this bug as the root cause of the problem our customer faced. In order to avoid commercial dispution we have no choice except to stop using Angular2 as our new framework before this bug was fixed. Please resolve this issue ASAP。

[mcgraphix]

For anyone interested in somewhat of a "solution" here is my example project showing how you can get some of the memory back by clearing out some references on the window: https://github.com/mcgraphix/angular4-memory-hack

[mischkl]

Still a problem, looks like we can never upgrade to Angular 4....

[e-cloud]

@tbosch the severity label is not correct, it should be upgraded to severity4

[codefactorydevelopment]

This issue is a bit crowded but i am in particular interested in leak caused by services that have properties, as pointed out on this issue. What is the status of that one?

[a-zen]

Is there any news on this? I also think this is duplicate of #17261

[winning-chahwan]

Yeah any update ? it seems this is notably worse in recent version of angular 4.4.1 (latest stable)

[DanielKucal]

I'm experiencing the same issue, even only one instance of HomeComponent and RestrictedComponent should live at time, prior instances are kept in the memory:

[nekkon]

Hey guys. This is a performance issue from December. I do consider it critical, especially for medium to large scale apps that have multiple views/components. I believe that this should had been solved in version5. Any comment on this? @mhevery @tbosch

[saurav1005]

Hey, we have started experiencing this issue in our application as well. Have implemented the practices - AOT, lazy loading, unscribing to observables, cleaning services properties on destroy of the component or module. However, the memory consumption keeps growing for the application and page becomes less responsive after some time.
Hoping a fix is available soon. Updating this is for Angular version 4.

[EreckGordon]

This looks like an abandoned pull request due to the fact that Dzmitry got banned, probably right around the time he sent it. I wounder if that would have fixed these issues.

[ugam44]

Is this still being looked at? I am on Angular 4.4.4 and still seeing this issue. Is this resolved in 5.0?

[fxmfr]

@ugam44 I'm on version 5.2.0 which is still affected...

[mlc-mlapis]

... so long ... I am a bit lost what to use for reproduction of the problem with the latest Angular and if the problem exist at all.

[RaedsLab]

Reproduction:

1- Create an Angular app
2- "Destroy" it
3- Repeat 1-2 ( a few times)
4- Check browser memory & nodes

[Toxicable]

@RaedsLab
looks fine to me https://stackblitz.com/edit/angular-gitter-pomh4u?file=app%2Fapp.module.ts
If you inspect this profile you'll notice the greens are DOM GC's and the blues are JS GC's, all is working fine here.

---

Profile-20180129T091914.zip

[mlc-mlapis]

@RaedsLab ... thanks ... but you mean ...

• create an Angular app -> open an Angular app in a new tab
• destroy it -> close the tab or just open anything unrelated to Angular in that tab

[mlc-mlapis]

@RaedsLab ... just repeated reloading of the same app ... the pattern is the same and GC recycling works during 5 secs ... (Chrome 64.0.3282.119, 64-bits on Windows 10 FCU) ...

[RaedsLab]

@Toxicable Thank you, I appreciate the effort. I looked in your stackblitz an it seems to be working, I will test this on a local app.

@mlc-mlapis Your results seem to be consistent with @Toxicable.

FYI these were the results I was getting on 17th of November 2017. Something might have gotten fixed meanwhile, or I might have been doing something wrong.

[hkevin]

I noticed that pages would eventually become unresponsive when navigating back and forth between pages in our application. When navigating away from a page, it seems like the old component would stay in memory, and when navigating back to that page, another instance of the component would be created alongside the old component.

https://stackblitz.com/edit/angular-gitter-ghqv23?file=app%2Fapp.module.ts

From the above example it looks like DOM nodes are never garbage collected and will continue to grow until the application crashes.

[mlc-mlapis]

@hkevin ... hmm, there is something related to the Stackblitz environment itself ... not sure that it comes directly from Angular ...

[hkevin]

@mlc-mlapis I experience the same issue from my application...

[tmakin]

@hkevin I just ran your example using a full screen stackblitz window in Chrome. I saw a similar pattern until I manually forced GC collection in chrome. Did you manually trigger a GC run in your screenshot?

[fxmfr]

@hkevin In my real world application I was able to get rid of same components/services kept in memory multiple times, by fixing some still attached event handlers and subscribed observables.

However, I experience same DOM nodes issue.
DOM nodes are not removed, even with manually triggered GC (stackblitz example and real world).

[mbrookson]

I am seeing the same thing with 5.0.2.

It seems like DOM nodes are never getting destroyed when creating new components, even though they don't seem to show in the Chrome 'Elements' tab. JS event handlers also seem to continue to grow according to the performance monitor.
With a page containing a Kendo grid with 500 rows we have seen up to almost 1GB of RAM being used by the application!

Refreshing the entire page resets the memory levels but then continues to grow again.

[walljm]

i'm experiencing the same problem as @mbrookson. I have an Ionic 3.9.2 app with angular 5.0.0. When i add a card the DOM Nodes count goes up. When i remove the card the DOM Nodes stay. The below image represents adding a card then removing it three times.

[OrbitalJeffL]

Any update on this? It's having a huge impact on our project and I'm looking for any workaround. Thanks.

[shameej]

ngOnDestroy is not getting called to unsubscribe my service calls. How to make sure ngOnDestroy is called when I move away to different component/page. If not then can we call it manually?

[minslay]

I experience same issue. I maintain an angular application (v5.2.0). Every 1/2 minute I refresh the content and it must repaint new components and delete old components.
I've been watching ngIf and it works properly. (DOM nodes not exist at HTML, but remain as detached nodes)

Any idea is welcome.

[ghetolay]

@minslay are you mixing content projection (<ng-content>) and structural directives (ngIf, ngFor...) ?

[minslay]

In my application I call my API to serve data.
I use *ngIf to paint my data, but if no records were found I paint a html template that uses

My code:

<ng-template ngFor let-item [ngForOf]="_realTimeline " >
  <ng-container [ngSwitch]="item.type">
    <date-bar *ngSwitchCase="'datetime'" [timeStamp]="item.data"></date-bar>
    <commit-bar *ngSwitchCase="'commit'" [commit]="item.data" ></commit-bar>
   ...
  </ng-container>
</ng-template>
<div fxFill *ngIf="_realTimeline.length==0">
    <ng-template #noResults>
        <no-results>
            <h1>No records found</h1>
        </no-results>
    </ng-template>
    <loading-results *ngIf="timelineSrv.loading; else noResults"></loading-results>
</div>

and my template contents the tag:

<div fxFill fxLayout="row" fxLayoutAlign="center center">
    <img fxFlex="15%" class="logo" src="assets/img/logo.svg" alt="logo">
    <div fxFlex="50%">
        <ng-content></ng-content>
    </div>
</div>

Can be that mix the cause of this issue??

Thanks!

[ghetolay]

I don't understand clearly your setup (we shall continue this elsewhere like gitter).

But basically if you have a component A with

<div *ngIf="">
 <ng-content></ng-content>
</div>

used on a parent component like

<componentA>
  <h2>Content</h2>
</componentA>

When ngIf is false, the content is detached from the DOM but not destroyed because the content lifecycle is tied to the component defining that content.

So in our example the <h2> is only destroyed when the parent component is.

See https://github.com/angular/angular/issues/13059#issuecomment-264598276 and https://github.com/angular/angular/issues/17983.

[minslay]

I'll take a look to my code, to check if I'm destroying properly parent component.
Thanks @ghetolay !!!

[brpradeepprabhu]

Hi guys,
@DanielKucal
i am also facing this bugs having many instance in the memory
on ngOnDestroy by adding the below code, the memory is released

Object.keys(this).map(k => {
this[k] = null;
})

[minslay]

Hi @ghetolay,
I deleted all my code with ng-content tags so there were not mix content (ng-content and ngif) but the problem keep on.

@brpradeepprabhu , where do I have to add that code? at all of my OnDestroy functions? I'm newbie with angular... :(

Thx for your help!

[brpradeepprabhu]

@minslay i am getting the same issues what @DanielKucal facing i have resolve this by creating a base component and extends all my component and implements ngOnDestroy

export class componentA extends BaseComponent implements OnInit ,OnDestroy

In base component

export class BaseComponent implements OnInit ,OnDestroy
{
constructor() {}
ngOnDestroy(){
Object.keys(this).map(k => {
this[k] = null;
})
}
}

The above will not remove the detached dom node. i am still analysing how to resolve this issues

[minslay]

Hi @brpradeepprabhu. I tried your solution but it didn't worked for me.
I added that code at the end of all my ngOnDestroy functions (over 20 Components) but I have the same results that previously.

I'll keep on investigating.

Thank you for your time!

[minslay]

I finally solved my issue.
The problem was that my application uses hammerJS and I have several matTooltip. You can see this link https://github.com/angular/material2/issues/8989 to know more about the issue.
My application don't need hammerJS utilities so I dismiss it and now it works properly

[last-Programmer]

We are also facing this huge problem. When bootstrapping our angular app in iframe the problem is happening. The memory keeps growing in the browser even though the iframe src is changed to different non angular application.

[anglemd]

What I had to do (for my IE-only app) was trap the DOM 'onclose' event and manually trigger a destructor method on each service (implemented with an rxjs subscription pattern). Those dependency injected services just weren't being cleaned up otherwise. With that in place, however, all memory now seems reclaimed when the window closes or the user navigates elsewhere.
The other thing I did was wrap all destructor methods (within services and components) with try/catch. If a javascript error is generated in a destructor, they are hard to catch, and can gum up the app cleaning itself up, so this extra step seemed to ensure cleanup proceeds normally regardless of any unforeseen errors.

[EndarValuk]

@anglemd could you provide xample? Thanks.

[anglemd]

Sure. Here's a quick example of what my particular app is doing to shut down the app when the browser closes (though there are several ways this could potentially be handled).

In my IE-only app I have a service (called WindowService) which has the single job of tracking when the browser window closes or resizes (so I can inform other components/services, if they "subscribe" to these events exposed by the service). The service calls this line in the constructor:
window.addEventListener("unload",this.handleWindowUnload, false );
This line associates the private service method "handleWindowUnload()" with the DOM "unload" event.
The handleWindowUnload method does two things: It fires an rxjs event (see below) so all observer objects can detect that the browser is about to close. Then it detaches itself from the DOM with the following line:
window.removeEventListener( "unload", this.handleWindowUnload, false );

So that's basically how the service knows IE is closing. Now it has to share that news with other services/classes....

The service exposes the following properties:
public windowUnload$ = this.windowUnloadSource.asObservable();
private windowUnloadSource = new Subject<void>();

Also, in my 'handleWindowUnload()' method, I call the line:
this.windowUnloadSource.next( );

All of this rxjs stuff basically allows other services in the app subscribe to the 'windowUnload$' observable, wait for the unload event, and then they can call their own destructor functions. With this pattern, I've been able to guarantee the destructors are always called. (To confirm whether a destructor is called, you can actually call alert( "I am being destroyed") from within the destructor and IE will display a pop up that interrupts the window actually closing).

My app is running in an embedded InternetExplorer control (IE 10 or IE 11 only) within another application, so I don't even have access to the typical browser developer tools. I can run Windows Task Manger, though, to track overall memory usage, and that has been sufficient to help me detect when a javascript memory leak occurs (which can happen if I should add a new service that does not fully clean up after itself).

I wish services automatically cleaned up after themselves in IE with the normal lifecycle hooks, but since they don't, I've settled on this manual approach to ensure all memory gets released. It's been working well enough. Hope that helps!

[akhilshastri]

This is a critical issue and still open.. Angular 👎

[brpradeepprabhu]

@anglemd
can you try this.

On Destroy of the component can you add this piece of code after u unsubscribe your rxjs services and make sure you have implemented OnDeStroy interface for the component

ngOnDestroy(){
Object.keys(this).map(k => {
this[k] = null;
})
}

[akhilshastri]

Yup, I saw this code snippet in above discussion. Don't you think it should take care by framework it self

[BaHXeLiSiHg]

Yeah, memory leak with enabled tooltips (when tooltip show some text) have place, can not understand with what is related :(

[BaHXeLiSiHg]

Maybe somehow connected with AsyncPipe node?

[kksevta]

Any updates, as in my app I can see continuous increment of nodes.

[freon27]

In our use case, we are loading and unloading multiple Angular apps and React apps. The react apps clean up after themselves properly but there is no memory usage reduction from the angular apps when destroying the modules (even with the most basic Angular 6 project).

Is there any traction at all on this issue? It's very hard for us to plan strategically when there's no indication of whether this will be fixed or we should look for another solution.

[RaedsLab]

@freon27 lucky we caught this early on, migrated all our UI to React and haven't looked back since.

I'm still subscribed to this issue months later, just to see if it will ever get resolved.

[pevans360]

After 8 months of climbing the Angular learning curve and getting the basics of our site working, we're finding major memory leaks going into beta testing. How is it that something this fundamental is this messed up?

[Itrulia]

@pevans360 most likely your issue is in your code if the problem is that big.

Check if you

• Are you ubsubscribing all the observables when the component destroys
• Don't provide the same service multiple times

The first one will usually be your memory leak.

[RaedsLab]

@Itrulia The issue could be in their code. But I have bootstraped 2 new HelloWorld applications and still have this issue.

[Itrulia]

I never had memory leaks that were an impactful problem (for example this one) from Angular itself.

Since he said he isn't very comfortable with Angular, not understanding RxJS is way more likely to be a problem.

[be-ndee]

@Itrulia do I need to unsubscribe when I subscribe on an observable, which is completed? So like this:

const observable = of<number>(1);
const subscription = observable.subscribe(
    (x: number) => console.log(x),
    error => console.error(error),
    () => console.log('completed')
);
subscription.unsubscribe(); // is this necessary?

[codefactorydevelopment]

@be-ndee the way you put it - its not necessary. BUT, if this code is in component and component gets destroyed before your observable completes - you have a leak.

So, its a rule of thumb: unsubscribe from everything you manually subscribed to.

[be-ndee]

So let's imagine I have a component with this ngOnInit method. And the component gets destroyed after 5 seconds (so the setTimeout is not finished yet), then I should unsubscribe from the observable in the ngOnDestroy method?

ngOnInit(): void {
    const observable = Observable.create(observer => {
        setTimeout(() => {
            observer.next(1);
            observer.complete();
        }, 10000);
    });

    observable.subscribe(() => {});
}

[FDIM]

@be-ndee yep, or you could adopt a takeUntil pattern:

// in some component
destroyed = new Subject();
ngOnInit(): void {
    this.service.getData()
      .pipe(takeUntil(this.destroyed))
      .subscribe((data) => {
       // do something else
   });
}
ngOnDestroy() {
   this.destroyed.next();
   this.destroyed.complete();
}

EDIT: I am not sure how one would cleanup timeout in your example though, normally I'd use interval or timer

[Itrulia]

Yeah setTimeout will not be cleaned up.

You only need to cleanup your component code if you are manually subscribing and the complete callback does not get called immediately (so no first() or of(), for example).

Most of the time you do not need to manually subscribe but use the async pipe, if you do manuall subscribe (for example when handling with reactive forms) you will need to cleanup after yourself. I can recommend using the takeUntil pattern shown aboth, there are even packages that abstract it away (but require you to have an empty ngOnDestroy method, which I don't like).

[pevans360]

@Itrulia Thanks.

We addressed the unsubscribe issue a while back using the takeUntil() pattern.

Found after last night's post that at least part of the current issue is related to HighCharts. After clicking around the site in Chrome and then taking a snapshot of the heap, there are hundreds of HC chart objects (at 50K each). They don't go away even after hitting the 'Collect Garbage' button.

Setting references to the chart objects = null in ngOnDestroy() didn't help, so seems like something else is preventing GC. Working on some other ideas, starting with our HC wrapper component.

[CanKattwinkel]

@be-ndee I'm using ng2-rx-componentDestroyed for handling subcriptions. Works like a charm.

Implement the OnDestroy Interface in your component and then you can use it like this:

Observable.interval(1000)
        .pipe(
            untilComponentDestroyed(this) // <--- magic is here!
        )
        .subscribe(console.log);

See: https://www.npmjs.com/package/ng2-rx-componentdestroyed

[Goldflow]

is there any generally accepted workaround
I see some suggestions but not sure if any people of Angular have any suggestions on this
was going to ask @DzmitryShylovich but someone mentioned he was banned? what is that about

[sliepchenko]

Same problem

[1pocketaces1]

@brpradeepprabhu I tried your fix, but even though you set everything to null, the memory is not deallocated, so over time it still builds up.

I just want to say, it is impossible to believe that a widely used framework like angular has such a terrible bug that renders bigger apps useless. I am having to rewrite my entire mobile app for React Native because of this and will forever tell people to stay far far away from angular

[ADjenkov]

We are hitting the same problem in NativeScript with our custom RouteReuseStrategy. We observe accumulating memory even after OnDestroy properly fired over destroyed Component.
We suspect that any injected dependencies are still there up and running, even after the component is gone.

[SudhakarSundar]

Is there any solution for this problem, it is hitting our application performance badly after a while in working on the application?

[Goldflow]

I think somehow this issue flew under the radar of the Angular team since they haven't responded to this for a very long time... I would say try to bring it under attention where you can to hopefully get this fixed sooner.

I've asked for extra information on angular & ngrx gitter and someone also opened a thread on this on reddit/r/angular2 but so far no official comments:

https://www.reddit.com/r/Angular2/comments/90oc2f/angular_bug_since_2016_memory_isnt_released/

[gabrielalack]

Same here. Having significant performance issues, that build up as you simply navigate around our app and thinking this may be very relevant.

[1pocketaces1]

Yes this is an issue with angular framework and has not been fixed in years. I advise you switch projects to React JS/Native!

I have been putting in hours to learn it and it's incredible. I don't doubt that React will soon be the foundation of most new internet applications.

[mlc-mlapis]

@1pocketaces1 ... lol, hours ... it sounds like really hard work.

[FDIM]

@gabrielalack I would recommend to investigate what is not released and why, it might be observables that are not cleaned up or something else keeping references. Memory tab in chrome dev tools is extremely useful and can easily show you the diff between heap snapshots and where the references are being kept.

[1pocketaces1]

@FDIM the js heap only builds up and never decreases. onDestroy() does not deallocate heap memory. Even the above mentioned solution of setting all objects to null before destroying is not a perfect fix as the memory is still allocated.

@mlc-mlapis its not too bad. It's an app with 7 pages across 4 tabs (not counting onboarding pages), aws lambda backend. Took 6 months to design/build in angular, but now that the designs and layouts are set it should take me just a couple weeks to rewrite in React Native. I can already see a big difference in performance reacting to button presses and tab switches

[mlc-mlapis]

@1pocketaces1 ... Is it a mobile app? ... finally, Angular optimized and bundled code is a bit faster than just React code. But it seems that you are talking about the different platform ... React Native ... so you probably need to compare with Angular -> NativeScript to get comparable numbers.

[1pocketaces1]

Ya its a mobile app. The performance of touches isn't a big enough difference to be important, though it is noticeable. It is the memory leak issue that this thread is about, that's why we left angular and cannot use it. With a project that has this number of pages with many components on each page, the js heap piles up and the app becomes un-usable after navigating around.

[codefactorydevelopment]

i have worked on several enterprise, big projects using angular (2-6) with alot of modules, features, even heavy dom manipulations, etc...
not only have i never experienced performance problems but all projects were blazingly fast & responsive.

not trying to advocate anything, just thinking out loud if there is something outside of angular per se causing this kind of problems. some particular pattern, lib, something...

[benelliott]

@1pocketaces1 The most likely reason is that you are not cleaning up observable subscriptions when your component is destroyed. The observable will retain a handle to any subscribers to it, so if you instantiate one component that subscribes to a particular observable a thousand times without unsubscribing then a thousand instances of that component will still be retained in memory.

[1pocketaces1]

@benelliott we did not use any observables. I know exactly what the issue was lol I pinpointed it with hours in devTools. Every object that was created remained in heap memory forever

[rmullins9]

I'll be updating my original demo app to version 6 soon to re-test this issue. Honestly we haven't seen memory leak problems in quite a while.

The biggest issue I found previously is that memory allocated to service properties was not being cleaned up, even after destroying the entire app. I believe they fixed that issue.

Still, as a best practice, we've ensured that no service holds props - it's a bad way to manage app state and will lead to other problems that are solved by ngrx.

[SudhakarSundar]

For me the problem started after using the customroutereuse strategy, the
components which I wanted to reuse after navigating away from that
component page and returning to the same component page, I see the memory
is getting built up without releasing.

On Tue, Aug 7, 2018, 1:12 PM 1pocketaces1 [e-mail] wrote:

@benelliott https://github.com/benelliott we did not use any
observables. I know exactly what the issue was lol I pinpointed it with
hours in devTools. Every object that was created remained in heap memory
forever

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular/issues/13725#issuecomment-411150426,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANNqcFivpavDY3A9rSh5ukGsoEOyAUlGks5uOdh3gaJpZM4LYXyb
.

[trotyl]

@rmullins9 I'd suggest close this issue if you don't have this issue any more, and let others open new issue per case (e.g. particular RouteReuseStrategy usage). This issue already goes off-topic and isn't possible for tracking the problem.

[rmullins9]

I retested the issue and can't reproduce it anymore. Under the same scenario, when navigating away from the components they are destroyed and allocated memory is cleaned up.

[briancodes]

On a related note, there was an issue where the ngOnDestroy() method of services provided with useFactory was never called. Any unsubscribing in the service ngOnDestroy e.g. $observableRef.complete() would be ignored. This could lead to components and views being retained in memory. This has been fixed in V6.1 beta https://github.com/angular/angular/commit/fc034270ced8f17cf17a82d3f8382dcef435b9a6

[pevans360]

My issue turned out to be related to Google Maps ...
https://issuetracker.google.com/issues/35821412

[rafael-andrade]

@benelliott I have been reading some blogs about unsubscribing observables and some blogs that I read say that I don't need to unsubscribe to all observables, for example, http requests, cause they do not maintain the observable in memory after the return. Is that true ?

[benelliott]

@rafael-andrade You do not need to unsubscribe from an observable if you know that it will complete before the component is destroyed. It is long-lived observables which you need to be careful with, since they will keep a reference to the subscribed component and thus it won't be destroyed until the observable completes, which could be after a long enough time that you have instantiated thousands of instances of it.

[rafael-andrade]

@benelliott I am really trying to get into observables, what do you mean when you say "it will complete". Does HttpClient.get from angular completes before components are destroyed? How can I check this kind of things? For example, I am subscribing to events from ngx-bootstrap modals (https://valor-software.com/ngx-bootstrap/#/modals). How can I know if its observable completes or not?
Sorry if it is a dumb question and thanks for the previous answer.

[1pocketaces1]

I wanted to contribute what my issue was in case someone coming here has the same. I was using ng-lottie to put bodymovin animations in my app. This was the cause as the lottie package does not remove any animation artifacts in the ngOnDestroy, so they are locked up in heap memory

[rafael-andrade]

@briancodes I was reading the HttpClient response code, it is something like this

        if (ok) {
          // A successful response is delivered on the event stream.
          observer.next(new HttpResponse({
            body,
            headers,
            status,
            statusText,
            url: url || undefined,
          }));
          // The full body has been received and delivered, no further events
          // are possible. This request is complete.
          observer.complete();
        } else {
          // An unsuccessful request is delivered on the error channel.
          observer.error(new HttpErrorResponse({
            // The error in this case is the response body (error from the server).
            error: body,
            headers,
            status,
            statusText,
            url: url || undefined,
          }));
        }

Does that mean that when occurs an error the observable does not complete or it completes somewhere else?

[cgatian]

Please take this discussion offline.

On Wed, Sep 5, 2018, 8:23 AM Rafael Andrade [e-mail]
wrote:

@briancodes https://github.com/briancodes I was reading the HttpClient
response, something like this

    if (ok) {
      // A successful response is delivered on the event stream.
      observer.next(new HttpResponse({
        body,
        headers,
        status,
        statusText,
        url: url || undefined,
      }));
      // The full body has been received and delivered, no further events
      // are possible. This request is complete.
      observer.complete();
    } else {
      // An unsuccessful request is delivered on the error channel.
      observer.error(new HttpErrorResponse({
        // The error in this case is the response body (error from the server).
        error: body,
        headers,
        status,
        statusText,
        url: url || undefined,
      }));
    }

Does that mean that when occurs an error the observable does not complete?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular/issues/13725#issuecomment-418710233,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABq8aqYt3_4Rh2M6kUxxi8s0bpwfeq4Cks5uX8JPgaJpZM4LYXyb
.

[benelliott]

@rafael-andrade If an observable errors it has terminated and will not emit any more values, in a similar way to when it completes. They are technically different events but yes, an error event closes the stream as well.

You can read more here:
http://reactivex.io/rxjs/manual/overview.html#executing-observables

[m0uneer]

@rafael-andrade
Check my answer at SO: https://stackoverflow.com/a/51732897/3100587?stw=2

[K0N0R]

I had this problem using single-spa
I found stupid workaround to memory leak problem.
try to put this code before angular modules load, maybe it will help you

import { TestabilityRegistry } from '@angular/core';
...
TestabilityRegistry.prototype.registerApplication = () => void 0;
TestabilityRegistry.prototype.unregisterApplication = () => void 0;
TestabilityRegistry.prototype.unregisterAllApplications = () => void 0;
TestabilityRegistry.prototype.getTestability = () => null;
TestabilityRegistry.prototype.getAllTestabilities = () => [];
TestabilityRegistry.prototype.getAllRootElements = () => [];
TestabilityRegistry.prototype.findTestabilityInTree = () => null;

it just prevent TestabilityRegistry to do anything, so it wont keep reference to module after unmount

[angular-automatic-lock-bot[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._}