search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.83k stars 21.13k forks source link

TabBar add_tab() Memory Leak Even With TabBar.clear_tabs() and TabBar.queue_free() Calls #82611

Open CamarataM opened 1 year ago

CamarataM commented 1 year ago

Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

System information

Godot v4.1.1.stable.mono - Windows 10.0.19045 - Vulkan (Compatibility) - NVIDIA GeForce GTX 1060 6GB (NVIDIA; 31.0.15.3713) - AMD Ryzen 5 5600G with Radeon Graphics (12 Threads)

Issue description

Whenever TabBar.add_tab() is called, memory usage increases for every tab as expected. However, after TabBar.clear_tabs() or TabBar.queue_free() is called, some of the memory used for that freed TabBar still remains and isn't freed (even though object and node counts stay the same). This causes a memory leak which is especially apparent if one is doing thousands of TabBar.add_tab() calls every frame, as leaked memory will slowly increase.

Related issue for ItemList can be found here.

Steps to reproduce

  1. Launch the attached project below.
  2. Monitor memory usage using Task Manager or Resource Monitor.
  3. Observe how memory usage continuously climbs to around 430 MB, even with TabBar.clear_tabs() calls and a final TabBar.queue_free() call.

Minimal reproduction project

TabBarMemoryLeakTest Minimal Reproduction.zip

echowarp commented 1 year ago

I built from the latest HEAD on this one too, and it does seem like this is currently fixed. Only 36.3MB of memory usage on Windows after 2,500 iterations then about 87.4MB after 4,000.

Running from the released 4.1.1 I do see the memory go up to 431.3MB.

Like the ItemList issue, it seems this one too must have been fixed already.

CamarataM commented 1 year ago

Quoting from the ItemList issue, as it also applies for this one:

Running the minimal reproduction on the latest release candidates 4.1.2 (v4.1.2.rc1.official [58f0cae4a]) and 4.2 (v4.2.dev5.official [e3e2528ba]), the bug still occurs, meaning that the bug was fixed somewhere between commit e3e2528ba7f6e85ac167d687dd6312b35f558591 and 0ca8542329888e8dccba89d59d3b728090c29991.