VirtGL: Fix memory leak in eglDestroyPixmap
authorFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Mon, 8 Jul 2013 15:32:39 +0000 (17:32 +0200)
committerjinhyung.jo <jinhyung.jo@samsung.com>
Wed, 11 Sep 2013 09:04:30 +0000 (18:04 +0900)
commita0b68b80e374075396266d7506d0c12b03ca0fdf
tree54b351f76368b901fa5df5513123d10d67b8d030
parentd27e3ba78df5d2794eaa2d8d010463d6b1760d77
VirtGL: Fix memory leak in eglDestroyPixmap

The code in qemu for glXDestroyPixmap make some verifications that fails :
if ( qsurface &&
     qsurface != process->current_state->current_qsurface &&
     qsurface->glstate == NULL &&
     qsurface->type == SURFACE_PIXMAP)
    /* free  image data */

We can see that before freeing surface : qemu checks that it is pixmap, it is
not current and it is not bound.

I added some traces and this is a sample from output :
[trace:qemu:opengl][2225]> glXDestroyPixmap
[trace:qemu:opengl]glXDestroyPixmap: 0x7f6898fff150
[trace:qemu:opengl]process->current_state->current_qsurface: (nil)
[trace:qemu:opengl]qsurface->glstate: 0x7f689801eef0
[trace:qemu:opengl]qsurface->type: 1, SURFACE_PIXMAP: 1
[trace:qemu:opengl]process->current_state: 0x1627680, qsurface->glstate:
0x7f689801eef0

We can interpret this as : the application requested to free the surface, but
it was still bound in the context.

The two following reasons suggest to resolve the leak by forcing unbinding the
image from qemu.
* Having a destroyed image in a context doesn't really make sense,
* In this use case it is likely that the context will be destroyed soon after
the pixmap.
tizen/src/hw/opengl_exec.c