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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downgraded Components are not garbage collected #39911

Closed
cryve opened this issue Dec 1, 2020 · 1 comment
Closed

Downgraded Components are not garbage collected #39911

cryve opened this issue Dec 1, 2020 · 1 comment
Labels
comp: upgrade memory leak Issue related to a memory leak P4 Low-priority issue that needs to be resolved state: has PR
Milestone

Comments

@cryve
Copy link

cryve commented Dec 1, 2020

馃悶 bug report

Affected Package

The issue may be caused by package @angular/upgrade

Is this a regression?

No.

Description

I have a hybrid app consisting of a main Angular CLI app that integrates legacy AngularJS templates via custom bundling and UI-Router. When I use a downgraded Angular component in an AngularJS template and toggle the rendering of this component with ng-if, let's say 5 times, then I can find 5 instances of the component in the heap snapshot.
This doesn't happen in a pure AngularJS template nor in a pure Angular template.

馃敩 Minimal Reproduction

https://github.com/cryve/angular-downgrade-memory-leak

馃實 Your Environment

Angular Version:


Angular CLI: 11.0.2
Node: 12.8.1
OS: darwin x64

Angular: 11.0.2
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router, upgrade
Ivy Workspace: Yes

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1100.2
@angular-devkit/build-angular   0.1100.2
@angular-devkit/core            11.0.2
@angular-devkit/schematics      11.0.2
@schematics/angular             11.0.2
@schematics/update              0.1100.2
rxjs                            6.6.3
typescript                      4.0.5

Anything else relevant?
AngularJS code is manually bundled by this script: https://github.com/cryve/angular-downgrade-memory-leak/blob/main/ngx/build.js
The upgrade setup has been inspired by this article: https://www.angulararchitects.io/aktuelles/directly-upgrading-from-angularjs-1-x/

@cryve cryve changed the title Downgraded Components are not destroyed Downgraded Components are not garbage collected Dec 1, 2020
@ngbot ngbot bot added this to the needsTriage milestone Dec 1, 2020
@jelbourn jelbourn added memory leak Issue related to a memory leak state: has PR P4 Low-priority issue that needs to be resolved labels Dec 2, 2020
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Dec 2, 2020
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of angular#26209 but for downgraded (instead
of upgraded) components.

Fixes angular#39911
Closes angular#39921
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of angular#26209 but for downgraded (instead
of upgraded) components.

Fixes angular#39911
Closes angular#39921
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of angular#26209 but for downgraded (instead
of upgraded) components.

Fixes angular#39911
Closes angular#39921
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of angular#26209 but for downgraded (instead
of upgraded) components.

Fixes angular#39911
Closes angular#39921
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 3, 2020
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of angular#26209 but for downgraded (instead
of upgraded) components.

Fixes angular#39911
Closes angular#39921
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 7, 2020
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of angular#26209 but for downgraded (instead
of upgraded) components.

Fixes angular#39911
Closes angular#39921
mhevery pushed a commit that referenced this issue Dec 8, 2020
鈥39965)

Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of #26209 but for downgraded (instead
of upgraded) components.

Fixes #39911
Closes #39921

PR Close #39965
@mhevery mhevery closed this as completed in 6dc43a4 Dec 8, 2020
twerske pushed a commit to twerske/angular that referenced this issue Jan 5, 2021
鈥gular#39965)

Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.

This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.

NOTE:
This is essentially the equivalent of angular#26209 but for downgraded (instead
of upgraded) components.

Fixes angular#39911
Closes angular#39921

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

angular-automatic-lock-bot bot commented Jan 8, 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 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
comp: upgrade memory leak Issue related to a memory leak P4 Low-priority issue that needs to be resolved state: has PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants