Possible memory leak. opengl3

[TheHiddenDuke]

Version/Branch of Dear ImGui:

Version: 1.72 WIP
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_opengl3.cpp
Compiler: llvm
Operating System: VxWorks 7

My Issue/Question:

I'm using the function to add primitives to the draw list for a single window. This renders the gui perfect, but there seems to be a memory leak as after 2 hours of running continuously the system crashes due to the lack of ram.

Here is the code used to initialize build up the screen. Only one window is used as a "canvas" to place all the primitives on. At most there is close to 300 objects that are drawn inside the draw_list.

gfxDisplay disp;
disp.init();

auto [width, height] = disp.getResolution();

auto [eglMajor, eglMinor] = disp.getVersion();

auto[a, b, g, r] = rgba(GetColor(TRANSPARENT));

glClearColorIuiEXT(r, g, b, a);

glEnable(GL_DEPTH);

height = std::max(1, height);

glViewport(0, 0, width, height);

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(-3.0, 3.0, -3.0, 3.0, 1.0, 10000.0);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

const char* glsl_version = "#version 130";

IMGUI_CHECKVERSION();
ImGui::CreateContext();
ImGuiIO& io = ImGui::GetIO();
(void)io;

ImGui::StyleColorsDark();

ImGui_ImplOpenGL3_Init(glsl_version);

while(running)
{
  ImGui_ImplOpenGL3_NewFrame();
  ImGui_ImplVxWorks_NewFrame();
  ImGui::NewFrame();

  ImGui::Begin("main", NULL, ImGuiWindowFlags_NoCollapse | ImGuiWindowFlags_NoResize | 
  ImGuiWindowFlags_NoSavedSettings | ImGuiWindowFlags_NoMove | 
  ImGuiWindowFlags_NoTitleBar | ImGuiWindowFlags_NoScrollbar);

    draw_list = ImGui::GetWindowDrawList();
    /* Call to multiple add functions, Addline, AddBezierCurve, PathArcTo, AddRectFilled, AddRect 
    andAddText */ 

     draw_list->AddLine(ImVec2(startX-(lineWidth/2), startY-(lineWidth/2)), 
                                     ImVec2(endX-(lineWidth/2), endY-(lineWidth/2)), 
                                     col, 
                                     lineWidth);
  ImGui::End();
  ImGui::Render();
  glClearColor((r / maxRGB), (g / maxRGB), (b / maxRGB), a);

  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

  ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData());

  disp.swapBuffer();
}
ImGui_ImplOpenGL3_Shutdown();
ImGui_ImplVxWorks_Shutdown();
ImGui::DestroyContext();

Hope someone can give some insight!

[ocornut]

There hasn't been a leak in ImDrawList since release afaik - we only keep buffer allocated accross frames but that doesn't accumulate.

So your issue is either:

1. There is an ever growing amount of content in the code you ommited "call to multiple add functions...". You can use the Metrics window to inspect what you are submitting.
2. There is an issue with your GL driver weere buffers are not recycled/freed properly (considering you are using a rather obscure OS that's not unlikely, GL drivers even under Windows are frequently bugged)
3. There is an issue with your VxWorks code which seems to be third-party code (is that code available).

Note that you could perfectly run your loop without any of the GL/VX code, only NewFrame+Begin/End/DrawList stuff/Render at a much faster speed and confirm if you get a leak which would mean the issue is in 1) not in 2) or 3). Similarly to could skip the GL rendering completely (removed glClear, RenderDrawData, swapBuffer) etc.

Either way until proven it doesn't seem like some code in the dear imgui repository is faulty.

[TheHiddenDuke]

Thank you for a quick reply and a descriptive answer!

I forgot to mention that I did run ImGui on windows without any sign of the memory leak, as well as I checked the Metrics window and it kept the same values. So I also doubt that dear imgui is the reason.

I don't really know a lot about openGl and how it interacts with imgui.
Would you have an idea of where to start looking?

[ocornut]

I already mentioned a way to easily differentiate 2 from 3 which would narrow it down to either OpenGL driver behavior or VxWorks back-end behavior. In both cases the problem is probably to be taken to the maker of that closed-source solution.

[ocornut]

Closing this because out of our support scope.

[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.