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

Jump to bottom

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 P4 state: has PR
Milestone
Backlog

Comments

@cryve
Copy link

@cryve cryve commented Dec 1, 2020 •
edited

🐞 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
@arturovt arturovt mentioned this issue Dec 1, 2020
Closed
14 tasks
@ngbot ngbot bot removed this from the needsTriage milestone Dec 2, 2020
@ngbot ngbot bot added this to the Backlog milestone Dec 2, 2020
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 3, 2020
@gkalpak
fix(upgrade): avoid memory leak when removing downgraded components
63b12e2 
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
@gkalpak
fix(upgrade): avoid memory leak when removing downgraded components
2839ba1 
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
@gkalpak
fix(upgrade): avoid memory leak when removing downgraded components
b667c27 
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 gkalpak mentioned this issue Dec 3, 2020
Closed
gkalpak added a commit to gkalpak/angular that referenced this issue Dec 3, 2020
@gkalpak
fix(upgrade): avoid memory leak when removing downgraded components
830b3b0 
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
@gkalpak
fix(upgrade): avoid memory leak when removing downgraded components
61baba2 
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
@gkalpak
fix(upgrade): avoid memory leak when removing downgraded components
0fe4233 
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 added a commit that referenced this issue Dec 8, 2020
@gkalpak @mhevery
fix(upgrade): avoid memory leak when removing downgraded components (#…
97310d3 
…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
twerske added a commit to twerske/angular that referenced this issue Jan 5, 2021
@gkalpak @twerske
fix(upgrade): avoid memory leak when removing downgraded components (a…
9c4f4bf 
…ngular#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 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.
Assignees
No one assigned
Labels
comp: upgrade memory leak P4 state: has PR
Projects
None yet
Milestone
Backlog
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
@petebacondarwin @jelbourn @cryve