Thanks! I don't have push permissions actually, so all my stuff is going
through the mailing list at the moment.
-John Sheu
On Thu, Apr 14, 2016 at 12:09 AM Alejandro Piñeiro
wrote:
> For next time, on the cases were minor changes are suggested, but a RB
> is granted in any case
The returned XVisualInfo from glXChooseVisual/glXGetVisualFromFBConfig
is being cached in XMesaVisual.vishandle (and unconditionally
overwritten on subsequent calls). However, these entry points are
specified to return XVisualInfo instances to be owned by the caller and
freed with XFree(), so the
Whoops. Patch updated on a different thread.
-John Sheu
On Sun, Apr 3, 2016 at 11:33 PM, Alejandro Piñeiro wrote:
> On 04/04/16 08:11, Alejandro Piñeiro wrote:
>> On 02/04/16 01:52, John Sheu wrote:
>>> XMesaVisual.vishandle is being unconditionally overwritten every time
&
The returned XVisualInfo from glXChooseVisual/glXGetVisualFromFBConfig
is being cached in XMesaVisual.vishandle (and unconditionally
overwritten on subsequent calls). However, these entry points are
specified to return XVisualInfo instances to be owned by the caller and
freed with XFree(), so the
On Tue, Apr 12, 2016 at 11:53 AM, John Sheu wrote:
> The XMesaVisual instances freed in the visuals table on display close
> are being freed with a free() call, instead of XMesaDestroyVisual(),
> causing a memory leak.
>
> Signed-off-by: John Sheu
> ---
> src/mesa/driv
Thanks for the heads-up. I only found one other place where a similar leak
occurs -- and in the case of xm_api.c, I figure that XMesaDestroyVisual()
is an "client-facing" call, so in the interest of maintaining layering
I've just made the appropriate free() call.
_
The XMesaVisual instances freed in the visuals table on display close
are being freed with a free() call, instead of XMesaDestroyVisual(),
causing a memory leak.
Signed-off-by: John Sheu
---
src/mesa/drivers/x11/fakeglx.c | 2 +-
src/mesa/drivers/x11/xm_api.c | 1 +
2 files changed, 2
---
src/mesa/drivers/x11/fakeglx.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index 208fc5bb..508dc65e 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fake
XMesaVisual.vishandle is being unconditionally overwritten every time
glXChooseVisual/glXGetVisualFromFBConfig returns a new XVisualInfo
instance, causing a memory leak.
---
src/mesa/drivers/x11/fakeglx.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git
This removes a hack introduced in 1999 in the first version of
fakeglx.c, with the comment:
/* XXX revisit this after 3.0 is finished. */
Mesa 4.0 was released in 2001. It is now 2016, and Mesa 11.0 was
released last year.
---
src/mesa/drivers/x11/fakeglx.c | 42 +++---
The vishandle member of XMesaVisualInfo is used to support the
comparison of XVisualInfo instances by pointer value, in
find_glx_visual(). The comparison however will always be false, as in
every case the comparison is made, the VisualInfo instance being
compared to is a new allocation passed in t
The XMesaVisual instances freed in the visuals table on display close
are being freed with a free() call, instead of XMesaDestroyVisual(),
causing a memory leak.
---
src/mesa/drivers/x11/fakeglx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/x11/fakeglx.c b/
12 matches
Mail list logo
