Mesa Memory Leak #62
Comments
|
Update: Compiling with gcc instead of Clang I was able to get some more detailed errors. Valgrind doesn't seem to be providing more detail necessarily, but I did catch something interesting: This suggests the issue is indeed directly in the tigrWindow function. |
|
Update: Further pursuing the leak, I followed the trail presented by Valgrind. It brought me to a snippet showing a pointer being overwritten without its memory being freed ( glc = glXCreateContext(dpy, vi, NULL, GL_TRUE);
int contextAttributes[] = { GLX_CONTEXT_MAJOR_VERSION_ARB, 3, GLX_CONTEXT_MINOR_VERSION_ARB, 3, None };
glc = glXCreateContextAttribsARB(dpy, fbConfig, NULL, GL_TRUE, contextAttributes);
glXMakeCurrent(dpy, xwin, glc);Not really sure what that first assignment is being used for, but I added a quick free of it before being overwritten as a little bandage. glc = glXCreateContext(dpy, vi, NULL, GL_TRUE);
int contextAttributes[] = { GLX_CONTEXT_MAJOR_VERSION_ARB, 3, GLX_CONTEXT_MINOR_VERSION_ARB, 3, None };
glXDestroyContext(dpy, glc);
glc = glXCreateContextAttribsARB(dpy, fbConfig, NULL, GL_TRUE, contextAttributes);
glXMakeCurrent(dpy, xwin, glc);(A cleaner solution would probably be to just not create the first context at all, but I'm not confident enough in my understanding to say it's not doing something in that one line between its creation and it being overwritten and that removing it entirely wouldn't break something.) GLXFBConfig* fbc = glXChooseFBConfig(dpy, DefaultScreen(dpy), attribList, &fbcCount);
if (!fbc) {
tigrError(0, "Failed to choose FB config");
}
fbConfig = fbc[0];Seeing this GLXFBConfig* fbc = glXChooseFBConfig(dpy, DefaultScreen(dpy), attribList, &fbcCount);
if (!fbc) {
tigrError(0, "Failed to choose FB config");
}
fbConfig = fbc[0];
XFree(fbc);However, bafflingly, Valgrind still reports memory issues from this line. Worth noting, there are no full leaks in the program by this point, only unfreed pointers. EDIT: I'm illiterate apparently, over 9KB are "possibly lost". Also interesting to note, with all these changes, compiling and running the program with LeakSanitizer doesn't seem to return any errors, but it does randomly crash on launch with a segmentation fault sometimes. I'm not certain when the segfault issue started, if it was something I did or if it's always been there, but I can say that after making the first change it would inconsistently return errors when the program terminated (perhaps related to how long the program ran for?) Overall, I think I've done everything I can. There are probably other instances of unfreed memory but they're likely all weird instances like this or trivial instances like the first one. But I'm a little overwhelmed and not quite motivated to hunt down more trivial instances when these weird instances run amook (but I can say it looks like |
|
So, it looks like indeed, this issue in particular is happening at a lower level, with the |
TIGR seems to cause memory leaks whenever it... runs. Clang Static Analyzer and htop return no issue, but Clang LeakSanitizer and Valgrind both freak out. LeakSanitizer output:
Valgrind's outputs are massive since it seems to print for each loop of the window, but it points in the same direction. Some sample lines:
Edit: It is not printing out errors for every loop, it just prints one massive block of errors on exit.
I'm running on Codespaces. I can't tell if the issue is with TIGR's useage of Mesa or Mesa itself, nor can I tell if this is an actual problematic leak or a false positive, but it seems worth calling attention to. Happens with any useage of TIGR, down to drawing an empty window.
Hopefully this helps track something down.
The text was updated successfully, but these errors were encountered: