question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Memory leak in Openlayers 6 beta

See original GitHub issue

Versions affected At least versions 6.0.0-beta.8 and 6.0.0-beta.7. This problem is not present in 5.3.0.

Description I have a situation where I need to quickly create and destroy maps. After upgrading to Openlayers 6 beta, I encountered a page crash after a while. The problem is that canvas/map is not destroyed, something is keeping it alive.

Map has three layers:

  • Two TileLayers
  • One VectorLayer (using the vector mode)

If I don’t initialize the vector layer, the map gets destroyed just fine (so the tile layers are ok). If I initialize the vector layer with just the default styles, map stays in memory after it is supposed to be destroyed.

To Reproduce Map is embedded in Vue.js component. When Vue.js component gets destroyed, the map instance is destroyed before Vue scraps the dom. I clear the vector layer with layer.getSource().clear(), layer.setSource(undefined) and map.removeLayer(layer). Then I try to destroy map with map.setTarget(null) and map = null. However, something stays in the memory. I’ve been hunting the cause with browser memory snapshot, and it clearly shows that canvas is not destroyed:

image

I’m kind of suspicious of the LabelCache doing something dirty, since it was added to the project this year. If it doesn’t ring any bells, I can try to create a live example of this problem.

Expected behavior Map/canvas does not stay in memory when it’s destroyed.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:12 (7 by maintainers)

github_iconTop GitHub Comments

4reactions
ahocevarcommented, May 16, 2019

The issue turned out to be something completely different. When #9561 is merged, it will be enough again to call map.setTarget(null) to release all resources.

2reactions
ahocevarcommented, May 16, 2019

Ok, I see what’s going on: the map renderer has no chance to schedule the removal of layer renderers, which would unregister the listener for label cache changes. See https://codesandbox.io/s/simple-zlehr, which disposes the layer renderer, which makes the leak go away.

I’ll see if we can fix that in the library.

Read more comments on GitHub >

github_iconTop Results From Across the Web

OpenLayers 6.1.1 Vector Layer Memory Leak
This is my code for destroying the layers. Has anyone encountered this issue in version 6 of OpenLayers post beta? const layers =...
Read more >
OpenLayers memory leak
VS Code's tsserver was deleted by another application such as a misbehaving virus detection tool. Please reinstall VS Code. Manage Extension.
Read more >
[New product] [beta] Whiteboard for Github Issues
Hey, we're building a collaborative whiteboard for teams who use Github issues (think an easy way to sort and prioritise issues for your ......
Read more >
How to fix the possible memory leak issue in Openlayers ...
After some memory leak detection approach three snapshot technique, I found that there is some memory leakage issue in OpenLayers.Control.
Read more >
cqi - River Thames Conditions - Environment Agency - GOV.UK
230 slk amg, Univers freebox proxy youtube, Shower head leaking from wall. ... Franciscan seminaries in california, Prov 6, Beta agonists hyperkalemia ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found