Loading GLTF memory could not be freed

Questions
1

This is the memory footprint of the page just opened

image
image851×43 3.26 KB

Repeatedly opening the page will continue to increase memory

image
image853×37 3.08 KB

Grid destruction
image
image291×793 10.5 KB

I do mesh and texture related destruction when I leave the page, but the memory is never freed

let that = this
debugger
this.scene.unregisterBeforeRender()
this.arcCameraTmp.dispose()

  let meshesLength = this.scene.meshes.length
  let meshes = this.scene.meshes
  for (let i = meshesLength - 1; i >= 0; i--) {
    meshes[i].dispose(false, true)
  }
  this.scene.meshes = []

  let transformNodesLength = this.scene.transformNodes.length
  let transformNodes = this.scene.transformNodes
  for (let i = transformNodesLength - 1; i >= 0; i--) {
    transformNodes[i].dispose(false, true)
  }
  this.scene.transformNodes = []

  let materIalsLength =  this.scene.materials.length
  let materials =  this.scene.materials
  for (let i = materIalsLength - 1; i >= 0; i--) {
    materials[i].dispose(true, true, false)
  }
  this.scene.materials = []

  let texturesLength =  this.scene.textures.length
  let textures =  this.scene.textures
  for (let i = texturesLength - 1; i >= 0; i--) {
    textures[i].dispose()
  }
  this.scene.textures = []
  this.scene.defaultMaterial.dispose(true, true, true)
  this.scene.dispose()
  if (that.engine) {
    that.engine.stopRenderLoop()
  }
  this.engine.dispose()
  this.engine.clear(null, true, true, true)
2

cc @bghgary and @RaananW (in case your tool could catch it)

@babylonjs197s could you share a repro???

3

We are only checking memory leaks in core ATM, but it will be a great help to add other libraries as well. I’ll add it to the tasks :slight_smile:

1 Like
4

It seems that actually you don’t dispose all meshes here. The same with materials etc.
Every time you dispose of a mesh scene.meshes.length gets shorter so gets to 0 before all meshes are disposed of. Use while loop.

while(scene.meshes.length {
var mesh = scene.meshes[0]
mesh.dispose();
}
1 Like
5

I miss that one :slight_smile: you are the best @labris

1 Like
6

Whether it’s for or while, I saw the mesh and Materials and Textures arrays were empty, and the memory was still not freed
image
image

7

And what happens after disposing the engine?

8

There is nothing left and it becomes a blank, but only part of the memory is released. If I open / close pages frequently, I can see that the memory is obviously increasing

9

Do you have other loops running (from other frameworks, for example)?

10

I made a demo without any nesting and tested it. I felt that it was a problem with the model. I changed other models and repeated loading n times. The memory can be destroyed, but if I changed back to the super large model, the memory can only be destroyed by half. But my model can’t be shared. You can find a larger model and load it. This is the address of the demo without redundant code:babylonjs: babylonjs
localhost:port/ This address can load the model
localhost:port/#/test This address can trigger the method of destroying instances by switching routes

11

Try to avoid Vue injecting reactive properties by setting _isVue = true on your scene class/object (ie. whatever you are using to wrap babylon).

12

image
image820×416 20.9 KB

Is that right?It doesn’t seem to have any effect. The memory still can’t be released

13

This is the memory used by the task manager after I finish loading

image
image847×40 3.31 KB

This is the memory after leaving the page and destroying the scene

image
image857×39 3.27 KB

I used the browser’s memory analyzer to take a heap snapshot to see if you can analyze the occupation and destruction of memory. I put it in that project address. babylonjs: babylonjs
Under the money folder

14

That’s not 100% correct, especially since the browser makes the decisions as to when to actually garbage-collect unneeded objects. It SHOULD be true, but i wouldn’t take that as the correct state.

Taking a memory snapshot (and counting the remaining/referenced objects) is the right way to go if you want to be sure if those objects were disposed.

Of course, I am not saying don’t have an issue, i’m just saying there is a safer way to check :slight_smile:

You can also start your browser with garbage-collection support turned on and call window.gc() when needed. But this is not recommended for a day-to-day usage.

15

I believe you have some memory leaks somewhere, but it would be better to make more extensive memory tests before, probably it would help to pinpoint the cause.

17

I called GC without any effect at all. I took a memory snapshot using the timeline of memory and found that there are many map, bytecodearray and promisereaction objects under the system, and the map has very deep recursion (about more than 100 layers of nodes). According to the memory analysis of the timeline, these memories have not been released. I don’t know what has been done in babylonjs.

image
image1711×912 73 KB

I put the snapshot here. Can you help me see what these are? What can I do to free up the occupied memory.

18

This seems to be an issue with the inspector and not directly with core. I’ll work on adding a few memory leak tests outside of core.

20

Hello, has the problem improved? I’m a little confused about this problem and it crashes me, every time I open it, I have to close the browser and reopen the page after a few minutes, and every time I click it, it takes 3 seconds for me to drag or rotate it. I think that’s why my model is so big.

image
image289×519 7.86 KB

21

Hard to tell without a PG or the script as @Cedric says. It can have many factors or even a combination of factors. It can be something as simple as a type error in the script (creating a loop). Or it could come from the model or it could come from an unknown bug. It’s nearly impossible to detect just like that.

1 Like