Memory leak on resize of secondary viewport

[jc211]

Version: 1.78WIP
Branch: Merged tables and docking
Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfwcpp
Compiler: MSVC
Operating System: Win10

When an imgui window is outside the main window and it is actively being resized, the memory does not stop increasing. One way of getting the memory to go back to normal is to redock the window and resize it there.

Minimal code to show bug:
https://github.com/jc211/BugReport-ImGui-01

[ocornut]

Hello,

I can see some increase with NVIDIA driver + GL or DX11 but it eventually goes down here. Have you tried waiting a little bit more? With Intel drivers it seems not increase noticeably. I think it's likely an issue with either GLFW or the GPU driver, I would say more likely with the GPU driver.

• First you should test with example_glfw_opengl3 since it is so similar to your repro.
• Try updating the GPU driver.
• Then try comparing with example_sdl_opengl3, example_sdl_directx11, example_win32_directx11 to see if it can be narrowed down to a library or a graphics back-end.
• See if a simple GLFW app (without dear imgui) just programatically resizing with glfwSetWindowSize() does that too..

I think it's extremely unlikely dear imgui has anything to do with it but it may be worth investigating.

Also see #3321 #3204 for the kind of things we have to deal with in Windows PC land...

[jc211]

I went through your checklist and found the problem:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
If the glfw OpenGL version is anything other than 3.0, it will cause a major memory leak as described above.

[OverShifted]

I have a Nvidia Geforce GTX 1050m (laptop edition) and nvidia driver version 445.75 and running Imgui 1.78 WIP on Windows10 and OpenGL 4.6 but I don't have that much memory leak

[ocornut]

If the glfw OpenGL version is anything other than 3.0, it will cause a major memory leak as described above.

In this case you want to be first testing this with both GLFW and SDL and see if there's a difference.

[jc211]

SDL has the same problem for me. I changed the loader too from GLEW to GLAD and it was the same deal.

I have a NVIDIA Quadro P3200 running driver 451.77

[ocornut]

Well I would say this is the way your driver behave. Note that I suspect if you wait long enough that memory will be released, it's probably only holding on it as a cache, rather than actually leaking the memory?
If not you should contact NVIDIA.

[jc211]

Ok, I will update this issue if I find anything new. For now I can close it. Thanks for your help.

[ocornut]

Hello @jc211 , do you have any update on this?

[ocornut]

Reverted the changes of #4468 with b8b0f9d, not using glBufferSubData() anymore.
PLEASE REPORT IF YOU STILL HAVE ISSUES AFTER TODAY.
I temporarily kept the alternative code path even though bd->UseBufferSubData is always false, allowing potential experiment shall new issues arises. Finger crossed this doesn't bite us back.

[jc211]

Hey @ocornut, I'm not currently using this functionality and no longer have the same setup as I did when I first opened this issue so I won't be able to report back. I'll keep this in mind if I do notice it on my new setup though. Thanks for your fix!