-
Notifications
You must be signed in to change notification settings - Fork 73
Memory Leak Issue #23
Comments
Looking at your code, it looks like you are not unloading the texture in your Try calling |
Interesting, thank you for catching that. I ran a few more quick tests, and I'll summarize the results below:
Running the sample code that I provided earlier, the memory used by the application remains stable between 7 MB - 13 MB. I hope this helps anyone else who encounters such an issue in the future. I will run more comprehensive tests shortly, and I will provide an update if the issue re-appears. As an aside note: could the documentation associated with the |
feel free to send PR to clarify the doc, but yeah basically any code doing |
if you destroy the gl context (aka unmount the view), I think you won't have to do that, but if you accumulate textures that you no longer use, you should probably call it to not leak memory |
Pull request has been submitted. Thank you for your help. Once again, I'll run some more extensive tests today and early next week, and if I notice that the issue still exists, I'll provide an update. If the issue still appears to be fixed once the testing is complete, I'll let you know and the issue can then be closed. |
Conducted some more tests, primarily on an emulated Android device with a memory profiler attached. Looks like the memory usage remains stable, This issue can be closed. |
I have run into an issue related to a memory leak. Effectively, after having disposed of a mesh (along with any linked geometry, texture, or material) and after ensuring that there are no longer any references to the mesh, the allocated space in memory is never freed when the garbage collector runs. Consequently, the application crashes should sufficient meshes have been created and later disposed.
For reference, I have uploaded sample code that illustrates this issue. The linked example creates a mesh using an image texture every 60 frames. The mesh is then deleted 30 frames after it is created. This process repeats indefinitely. If a memory profiler is attached to the process, it can be noticed that the allocated memory always continues to increase rather than fluctuating and stabilizing around a central value as may be expected. Find linked an image from a memory profiler that was attached to the above example code.
More details related to the testing that was conducted are listed below:
The testing scenarios as numbered in the table above are:
disposeImage()
disposeImage()
I believe the issue is related to the react-native-webgl library, and it is not related to Three JS due to scenario 5 above. With the exception of how the image itself is loaded due to a difference in target platform, the rest of the code in scenario 5 is almost the same as in scenario 4. Yet, the memory leak example is present in scenario 4 and not in scenario 5. Find linked sample code for scenario 5.
It is also interesting to note that the amount of memory allocated after 1 minute 30 seconds is approximately 60-65 MB in scenario 3, and is approximately 95-100 MB in scenario 4. There appears to be a noticeable increase in the memory leak when
scene.remove(mesh)
is called versus when it is not called.From the testing conducted, I wonder if the react-native-webgl library is keeping a reference to the created texture or mesh somewhere, and hence preventing the allocated memory from being freed?
The text was updated successfully, but these errors were encountered: