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

Application stays in memory even after being destroyed #22106

Closed
mcgraphix opened this issue Feb 8, 2018 · 3 comments · Fixed by RatkoR/angular#1
Closed

Application stays in memory even after being destroyed #22106

mcgraphix opened this issue Feb 8, 2018 · 3 comments · Fixed by RatkoR/angular#1
Labels
comp: core Runtime issues core: bootstrap core: performance freq3: high memory leak Issue related to a memory leak P3 Medium priority issue that needs to be resolved state: confirmed type: bug/fix
Milestone

Comments

@mcgraphix
Copy link

@mcgraphix mcgraphix commented Feb 8, 2018

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or 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 the platform is destroyed, the DOM node is removed but the application still exists in memory. This is easily verified by taking a heap snapshot after destruction of the platform.

Expected behavior

When the application is destroyed using PlatformRef.destroy() or even if the DOM node was removed manually, the application should not continue to exist in memory.

Minimal reproduction of the problem with instructions

Here is a simple stackblitz application that illustrates the problem: https://angular-h1zvzr.stackblitz.io/

  • Take a heap snapshot and you will see references to ApplicationRef, PlatformRef, and other Angular classes in memory
  • Click the "destroy" button. This calls destroy() on the platform ref that was temporarily stored on the window by the default stackblitz angular application. It then deletes the reference off the window.
  • Notice the application appears to be gone as the DOM nodes have been removed.
  • Take a heap snapshot and the references are still there.

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

In a portal environment where applications may come and go as the user navigates around, this causes a significant memory leak when the applications are not cleaned up.

Environment


Angular version: 2 - 5


Browser:
- [x] Chrome (desktop) version 63
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 56
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: 6.11.3 but probably happens regardless  
- Platform:  Mac (but probably any)

Others:

This is related to #13725 but that defect seems to have conflated several different things into one conversation.

@mhevery mhevery added the comp: core Runtime issues label Feb 13, 2018
@chuckjaz chuckjaz added type: bug/fix freq3: high memory leak Issue related to a memory leak labels Feb 15, 2018
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Feb 26, 2018
RatkoR pushed a commit to RatkoR/angular that referenced this issue Apr 4, 2018
When an application reference is destroyed it stays in memory because it is still registered in the testability registry.

Closes angular#22106, angular#13725
@msms007
Copy link

@msms007 msms007 commented Jun 5, 2018

any info about when this gets released?

@pkozlowski-opensource
Copy link
Member

@pkozlowski-opensource pkozlowski-opensource commented May 29, 2020

I can still confirm this issue in Angular v9 running ivy: https://stackblitz.com/edit/angular-8gx4rp?file=src%2Fmain.ts

There is a PR #22238 that correctly identifies TestabilityRegistry as one of the retainers but it might be more to it. We should definitively try to merge #22238 and re-run this scenario to make sure that all is released properly.

@jelbourn jelbourn added the P3 Medium priority issue that needs to be resolved label Oct 1, 2020
@mhevery mhevery closed this as completed in df27027 Dec 2, 2020
mhevery pushed a commit that referenced this issue Dec 3, 2020
…root view is removed (#39876)

In the new behavior Angular removes applications from the testability registry when the
root view gets destroyed. This eliminates a memory leak, because before that the
TestabilityRegistry holds references to HTML elements, thus they cannot be GCed.

PR Close #22106

PR Close #39876
@angular-automatic-lock-bot
Copy link

@angular-automatic-lock-bot angular-automatic-lock-bot bot commented Jan 2, 2021

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 Jan 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
comp: core Runtime issues core: bootstrap core: performance freq3: high memory leak Issue related to a memory leak P3 Medium priority issue that needs to be resolved state: confirmed type: bug/fix
Projects
None yet
6 participants