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

Fix a memory leak in DownloadTaskManager and DataTaskManager #7408

Merged
merged 1 commit into from Mar 20, 2024

Conversation

ahoppen
Copy link
Contributor

@ahoppen ahoppen commented Mar 19, 2024

DownloadTaskManager had a strong reference to URLSession, which retained its delegate, which was the DownloadTaskManager. This formed a retain cycle.

Make the reference from URLSession to the delegate weak and only keep DownloadTaskManager alive as long as DownloadTasks need it. This causes the DownloadTaskManager to be deallocated once nobody holds a reference to it anymore and all the tasks it manages are finished.

Finally, we need to call invalidate on the URLSession to tell it that we’re done and that it should release its delegate (which is now the WeakDownloadTaskManagerwrapper).

This retain cycle was causing a leak in sourcekit-lsp. I verified that the leak no longer exists with this patch.

rdar://125012584

@ahoppen
Copy link
Contributor Author

ahoppen commented Mar 19, 2024

@swift-ci Please test

@MaxDesiatov MaxDesiatov self-assigned this Mar 19, 2024
@ahoppen ahoppen force-pushed the ahoppen/download-data-task-manager-leak branch 2 times, most recently from 179445f to 3572bdc Compare March 20, 2024 10:23
@ahoppen
Copy link
Contributor Author

ahoppen commented Mar 20, 2024

@swift-ci Please test

@MaxDesiatov
Copy link
Member

@swift-ci test windows

`DownloadTaskManager` had a strong reference to `URLSession`, which retained its delegate, which was the `DownloadTaskManager`. This formed a retain cycle.

Make the reference from `URLSession` to the delegate weak and only keep `DownloadTaskManager` alive as long as `DownloadTask`s need it. This causes the `DownloadTaskManager` to be deallocated once nobody holds a reference to it anymore and all the tasks it manages are finished.

Finally, we need to call `invalidate` on the `URLSession` to tell it that we’re done and that it should release its delegate (which is now the `WeakDownloadTaskManager`wrapper).

rdar://125012584
@ahoppen ahoppen force-pushed the ahoppen/download-data-task-manager-leak branch from 3572bdc to 614a502 Compare March 20, 2024 12:57
@ahoppen
Copy link
Contributor Author

ahoppen commented Mar 20, 2024

@swift-ci Please test

@ahoppen
Copy link
Contributor Author

ahoppen commented Mar 20, 2024

@swift-ci Please test Windows

Copy link
Member

@MaxDesiatov MaxDesiatov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@ahoppen ahoppen merged commit d3ee3f6 into apple:main Mar 20, 2024
5 checks passed
ahoppen added a commit that referenced this pull request Mar 25, 2024
#7416)

* **Explanation**: `DownloadTaskManager` had a strong reference to
`URLSession`, which retained its delegate, which was the
`DownloadTaskManager`. This formed a retain cycle.
Make the reference from `URLSession` to the delegate weak and only keep
`DownloadTaskManager` alive as long as `DownloadTask`s need it. This
causes the `DownloadTaskManager` to be deallocated once nobody holds a
reference to it anymore and all the tasks it manages are finished.
Finally, we need to call `invalidate` on the `URLSession` to tell it
that we’re done and that it should release its delegate (which is now
the `WeakDownloadTaskManager` wrapper).
This retain cycle was causing a leak in sourcekit-lsp. I verified that
the leak no longer exists with this patch.
* **Scope**: The change should be transparent to all users of
`DataTaskManager` and `DownloadTaskManager` and only prevent the memory
leak
* **Risk**: I don’t see a risk with this change since the
`{Data|Download}TaskManager` is kept alive as long as there is anything
left that might call it.
* **Testing**: I verified that the leak no longer exists with this
patch.
* **Issue**: rdar://125012584
* **Reviewer**: @MaxDesiatov on
#7408
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants