-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
fix(core): memory leak if view container host view is destroyed while view ref is not #40219
Conversation
7e2367c
to
30d0d5b
Compare
… view ref is not When we attach a `ViewRef` to a `ViewContainerRef`, we save a reference to the container onto the `ViewRef` so that we can remove it when the ref is destroyed. The problem is that if the container's `hostView` is destroyed first, the `ViewRef` has no way of knowing that it should stop referencing the container. These changes remove the leak by not saving a reference at all. Instead, when a `ViewRef` is destroyed, we clean it up through the `LContainer` directly. We don't need to worry about the case where the container is destroyed before the view, because containers automatically clean up all of their views upon destruction. Fixes angular#38648.
30d0d5b
to
f82f03d
Compare
"packages/core/src/error_handler.ts", | ||
"packages/core/src/errors.ts", | ||
"packages/core/src/view/types.ts", | ||
"packages/core/src/linker/component_factory.ts" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Always a good sign when bunch of circular refs get removed!
❤️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed-for: circular-dependencies
… view ref is not (#40219) When we attach a `ViewRef` to a `ViewContainerRef`, we save a reference to the container onto the `ViewRef` so that we can remove it when the ref is destroyed. The problem is that if the container's `hostView` is destroyed first, the `ViewRef` has no way of knowing that it should stop referencing the container. These changes remove the leak by not saving a reference at all. Instead, when a `ViewRef` is destroyed, we clean it up through the `LContainer` directly. We don't need to worry about the case where the container is destroyed before the view, because containers automatically clean up all of their views upon destruction. Fixes #38648. PR Close #40219
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
When we attach a
ViewRef
to aViewContainerRef
, we save a reference to the container onto theViewRef
so that we can remove it when the ref is destroyed. The problem is that if the container'shostView
is destroyed first, theViewRef
has no way of knowing that it should stop referencing the container.These changes remove the leak by not saving a reference at all. Instead, when a
ViewRef
is destroyed, we clean it up through theLContainer
directly. We don't need to worry about the case where the container is destroyed before the view, because containers automatically clean up all of their views upon destruction.Fixes #38648.