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: memory leak event error is not unsubscribing #8591

Merged
merged 4 commits into from Apr 28, 2020
Merged

fix: memory leak event error is not unsubscribing #8591

merged 4 commits into from Apr 28, 2020

Conversation

jony89
Copy link
Contributor

@jony89 jony89 commented Feb 5, 2020

the event listener to scene renderError is only subscribing. causing memory leak upon cesium .destory()

the event listener to scene `renderError` is only subscribing. causing memory leak upon cesium `.destory()`
@cesium-concierge
Copy link

Thanks for the pull request @jony89!

  • ✔️ Signed CLA found.
  • CHANGES.md was not updated.
    • If this change updates the public API in any way, please add a bullet point to CHANGES.md.
  • ❔ Unit tests were not updated.
    • Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

  • Cesium Viewer works.
  • Works in 2D/CV.
  • Works (or fails gracefully) in IE11.

@jony89
Copy link
Contributor Author

jony89 commented Feb 26, 2020

@emackey ?

@mramato
Copy link
Member

mramato commented Feb 26, 2020

@jony89 Sorry no one has reviewed or replied to this so far. I'll take a look now and thank you for the PR.

@@ -671,6 +672,9 @@ import getElement from '../getElement.js';
* removing the widget from layout.
*/
CesiumWidget.prototype.destroy = function() {
if (this._scene) {
this._scene.renderError.removeEventListener(this._onRenderError);
Copy link
Member

Choose a reason for hiding this comment

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

Since we are destroying the scene on the next line, why do we need to unsubscribe the event listener? Destroying the scene should ensure that renderError and any subscriptions get cleaned up. Do you have an example that shows that's not happening?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Take any scene destroy it, and do heap delta between the stages (could be done easily with chrome devtool) and you will see that all the references to the scene are still exist in the memory. because of this event. it never unsubscribes and the references are kept. even if scene is being destroyed, someone is still holding the reference to this callback, so it will never be cleaned by the GC.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry for the slow roll here, I somehow missed this response. While I'd still like to understand the circular dependency causing the GC not to clean up the memory, no reason we can't err on the side of caution here and properly clean up after ourselves. I merged in master and updated CHANGES. I'll merge as soon as CI is happy. Thanks @jony89

Copy link
Contributor Author

@jony89 jony89 Apr 28, 2020

Choose a reason for hiding this comment

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

It's less of a circular dependency more like closures and references that stay alive while the anonymous function still have reference. I've discovered it by using heap snapshots and their deltas, one snapshot before destroying the viewer and one afterwards.
I have also tested that code and indeed it removes these references
Thanks @mramato .

@jony89 jony89 requested a review from mramato March 18, 2020 13:01
@cesium-concierge
Copy link

Thanks again for your contribution @jony89!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@jony89 jony89 mentioned this pull request Apr 2, 2020
@cesium-concierge
Copy link

Thanks again for your contribution @jony89!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@mramato mramato merged commit 55e2de9 into CesiumGS:master Apr 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants