Memory leak caused GLFW

support
1

The very short code below makes a memory leak,

I used valgrind-3.19.0 from the debian repository to detect it.
GLFW 3.4 and the code below was compiled with gcc 12.2.0
gcc memoryTest.c -o memoryTest -L ./glfw-3.4/build/src/ -I./glfw-3.4/include/ -lglfw3 -lm
GLFW was compiled with GLFW_BUILD_X11=0, I use Wayland.

#include <GLFW/glfw3.h>

int main(){
    glfwInit();
    glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
    glfwDestroyWindow(glfwCreateWindow(80u, 10u, "", NULL, NULL));
    glfwTerminate();

    return 0;
}

After testing it appears that the line

glfwDestroyWindow(glfwCreateWindow(80u, 10u, "", NULL, NULL));

causes the leak.

~$ valgrind --leak-check=full --show-leak-kinds=all ./memoryTest
[...]
LEAK SUMMARY:
   definitely lost: 3,824 bytes in 9 blocks
   indirectly lost: 15,857 bytes in 656 blocks
   possibly lost: 3,370 bytes in 9 blocks
   still reachable: 519,026 bytes in 7,168 blocks

I am not sure if this is a GLFW issue or Valgrind. Either way It’s annoying because my own code may leak and I can’t use Valgrind reliably if GLFW tempers with the results. Can I fix this?

2

It’s difficult to know where the leak lies without further investigation, and it might not be a leak in GLFW.

I am not sure whether closing a window immediately after creating it is supported, so I would ensure you run a normal event loop as per the GLFW documentation.

I would then ensure you build the entire codebase (including GLFW) with debugging information and look at detailed leak output following The Valgrind Quick Start Guide. This will also help you to isolate any memory leaks in your code vs GLFW - note that many GLFW calls will appear to leak because the dependencies (OS, drivers etc.) may lazily clean up memory.

3

The original code had an event loop, so that can’t be. You’re right, it’s hard to know without looking further. Also I use Linux, so the drivers comes from the Kernel, if they have a leak that’d be worrying and beyond me to fix it. One good thing is it always leaks always the same amount of memory, this way I can tell if I caused it or if it was external. Thanks for the reply.

4

That kind of leaks typically come userspace libraries that talk to these kernel drivers. Not the memory leak in drivers itself. Just in libraries like libGL.so from mesa/nvidia & similar vendors. It’s very common in opengl/vulkan & similar graphics related dll’s. Sometimes even in x11 and wayland libraries. They just have some global variables that get malloc’ed on initialization, and never released. Obviously all the memory is correctly released when your process terminates.

5

I noticed the same behavior, but only with very basic programs similar to this one. It only happens on some GNU/Linux distributions, not all of them. For example, there is no memory leak on Void Linux, while Valgrind reports just 24 bytes “definitely lost” on Debian (using a test program almost identical to yours). Your case, however, is somewhat different because the leak is more serious than just a few bytes. I noticed something like that as well, but only on some 32-bit cases, and even there the behavior varies depending on the distribution used.

My best guess is this is not related to GLFW itself, but rather to underlying libraries, such as libGL and how they are implemented in specific distributions, as @mmozeiko already mentioned.