Backport of prevent memory leak when using control group factors in a policy into release/1.10.x #17557
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This PR is auto-generated from #17532 to be assessed for backporting due to the inclusion of the label backport/1.10.x.
The below text is copied from the body of the original PR.
The problem might actually be that the Policy object is cached in the policy store's LRU. Then, we are assigning existingPerms.ControlGroup = pc.Permissions.ControlGroup. This is a pointer to the policy's control group. Then on next iteration we are appending another policy's control group factors to this one, making the actual policy object in the LRU cache larger. This causes the policy in the cache to no longer match the policy on disk.
Instead of using a map and de-duplicating factors i think we want to clone the original Policy's control group so we aren't reusing the pointer and mutating cache objects. If we clone the control group then any factors that we append to it will only live for the lifetime of the request and be garbage collected afterwards. This behaves similarly to the other data structures embedded in the ACL object.
Overview of commits