memory leaks due to dri refcounting
I've been hunting down some memory leaks (unrelated to this issue) but when taking closer look I noticed that iris driver's iris_screen_destroy
is not getting called. Every created resource holds a reference to screen so issue is that some of the resources never get freed. I noticed render buffers being one of these things and bisected this.
Can be reproduced with:
valgrind --leak-check=full --keep-debuginfo=yes --track-origins=yes glxgears
------------------------- 8< ------------------------------------
768238fdc06eed3dce36da3baf811cb70db42b5c is the first bad commit
commit 768238fdc06eed3dce36da3baf811cb70db42b5c
Author: Adam Jackson <ajax@redhat.com>
Date: Mon Jul 11 19:30:05 2022 -0400
glx: Fix drawable refcounting for naked Windows
driFetchDrawable is only ever called from the MakeCurrent path, which
means it has to handle the case of pre-GLX-1.3 Windows being named as
the drawable. When it finds the drawable in the hash, it increments its
refcount before returning it, so for a GLXWindow it would be 2 on first
return, one from glXCreateWindow and one from glXMakeCurrent. But when
it does not find the drawable and creates one for the naked Window, the
reference count on first return would only be 1. As a result, if this
context was then ever bound to a different drawable, the old Window's
DRI drawable state (like the back buffer) would be destroyed.
Fixes piglit's glx-multi-window-single-context and glx-make-current for
a variety of drivers.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6713
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17479>