Cesium: can not release memory

[lybc]

I used cesium in the angular2 to create an earth component. like this

When this component is logged off I have manually destroyed the viewer objectand when I destory this component

ngOnDestroy() {
  this.viewer.entities.removeAll();
  this.viewer.destroy();
}

In my program, this component is in a state of rotation that is constantly created and destroyed.

But I found that when the component is created will take about 100MB of memory, and in the destruction will not release memory. So when the program runs for some time, the memory consumption is very alarming.

I worry that there will be some memory leaks, there is no way to manually release the memory occupied by webgl?

[mramato]

@lybc thanks for the report. I'm not sure if this is a memory leak or the browser just being greedy about holding onto memory but we should definitely look into it to be sure. I wrote a reduced test case for Sandcastle that shows the problem you're describing.

var viewer = new Cesium.Viewer('cesiumContainer');

Sandcastle.addToolbarButton('Go', function() {
    setInterval(function() {
      viewer.destroy();
      viewer = new Cesium.Viewer('cesiumContainer');
    }, 1000);
});

Basically this code runs and memory goes up fairly quickly but at some point Chrome starts to do it's "Too many active WebGL contexts" thing and then memory goes back down slightly and continues to ping pong back and forth. It's entirely possible that this is just how the browser behaves (unfortunately we only have so much control over memory allocation), but it's also possibly something we can improve.

@lilleyse or @pjcozzi any thoughts here? Is it possible that we are leaving something uncleaned up which is causing the context to stick around?

[pjcozzi]

This is likely the browser, but we'll look when we can.

[ggetz]

Reported on the forum: https://groups.google.com/forum/#!topic/cesium-dev/FEtAFuPWKnk

[OmarShehata]

Reported again on the forum with a Sandcastle to recreate it: https://groups.google.com/d/msg/cesium-dev/VNWjO3qGrXE/lLUDzBX4DQAJ

I think this is a browser thing, but something we could do is allow users to re-use a WebGL context. I believe Threejs exposes a context option for this sort of scenario.

[OmarShehata]

Came up again here: https://groups.google.com/d/msg/cesium-dev/Mg6OlJCMwoQ/EV_uD-eLAAAJ

[mramato]

@OmarShehata my original code snippet no longer causes large memory increase in Chrome. We should be able to just close this. Everything else is outside of our control so there's no reason to keep this issue open. As long as Viewer.destroy is being called, memory gets freed.

Please confirm https://github.com/CesiumGS/cesium/issues/5462#issuecomment-308130948 doesn't lead to unbounded memory growth or anything like that for you.

[OmarShehata]

It does continue to grow, very slowly, but eventually plateaus around 300 mb of memory used (looking at the memory tab in the Chrome developer tools) which might just be the garbage collector doing its thing.

I am OK with closing now with the advice that re-using the Viewer object may still be a good idea in your applications (as it is to generally pool resources instead of creating and destroying when possible).

[cesium-concierge]

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/forum/#!topic/cesium-dev/FEtAFuPWKnk
https://groups.google.com/d/msg/cesium-dev/VNWjO3qGrXE/lLUDzBX4DQAJ
https://groups.google.com/d/msg/cesium-dev/Mg6OlJCMwoQ/EV_uD-eLAAAJ

If this issue affects any of these threads, please post a comment like the following:

The issue at https://github.com/CesiumGS/cesium/issues/5462 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.