At least the DRM/Intel module continues to suck up memory just by resizing the window. This would be acceptable behaviour if it wouldn't continue to grow on and on, as it happens for software rendering. This can not only be reproduced with a (potentially buggy) selfwritten test program but also with the glxdemo.c program from Mesa. To reproduce, start the test program and make the window smaller, and larger, and smaller again quite wildly and often (10-30 seconds or so). What happens if you start it with LIBGL_ALWAYS_SOFTWARE=1: Memory usage goes up to about 10M and stays there. What happens if you start it without that option set (DRM/Intel): Memory usage continues to grow with every resize operation even when the window size is only changed around 100x100 +-5px. Excerpt from Valgrind output (it had lots of those): ==11088== 3,244,032 bytes in 99 blocks are still reachable in loss record 331 of 331 ==11088== at 0x4C221A7: malloc (vg_replace_malloc.c:195) ==11088== by 0x7B3A822: ??? (in /usr/lib/libdrm_intel.so.1.0.0) ==11088== by 0x74B2344: ??? (in /usr/lib/dri/i965_dri.so) ==11088== by 0x74B41AD: brw_validate_state (in /usr/lib/dri/i965_dri.so) ==11088== by 0x74A6DBD: brw_draw_prims (in /usr/lib/dri/i965_dri.so) ==11088== by 0x75641A4: vbo_exec_vtx_flush (in /usr/lib/dri/i965_dri.so) ==11088== by 0x7560154: vbo_exec_FlushVertices_internal (in /usr/lib/dri/i965_dri.so) ==11088== by 0x7560221: vbo_exec_FlushVertices (in /usr/lib/dri/i965_dri.so) ==11088== by 0x74DB15D: _mesa_Flush (in /usr/lib/dri/i965_dri.so) ==11088== by 0x4E4C2B1: glXSwapBuffers (in /usr/lib/libGL.so.1.2) One test run got 23 MiB of still accessible memory all from libdrm. I don't think it's used for anything useful, if not because of the size, then because of the fact the software renderer does not leak.
Created attachment 33521 [details] full valgrind output of a test run For completeness I have attached a more complete Valgrind output file of a test run with the glxdemo program.
We also experience the same bug with Intel, our application works well with NVidia though.
Created attachment 33527 [details] extensive valgrind logfile The memory leak only happens during the application runtime, when deinitialization functions are called all the memory is cleaned up and no memleak occures. The attached valgrind output shows up all debug symbols. We ran a sample application (test.c which we will attach right after this post) and interrupted it with ctrl-c before deinitialization.
Created attachment 33528 [details] test.c
Created attachment 33529 [details] valgrind of the application without resizing it
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/drm/issues/2.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.