Comment 31 for bug 360319

Created an attachment (id=26280)
A simple test case using GTK+ and Clutter.

This is an example that exercises the leak in GEM objects. It leaks about ten windows worth on each execution.

Running this with Valgrind and filtering through the false positives I did find:

==3627== 3,520,000 bytes in 11 blocks are still reachable in loss record 2,603 of 2,603
==3627== at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==3627== by 0x53BE86A: _mesa_soft_renderbuffer_storage (renderbuffer.c:1202)
==3627== by 0x5395964: _mesa_resize_framebuffer (framebuffer.c:285)
==3627== by 0x5365579: intel_resize_buffers (intel_fbo.c:260)
==3627== by 0x530AC39: driUpdateFramebufferSize (drirenderbuffer.c:211)
==3627== by 0x532DC90: intel_update_renderbuffers (intel_context.c:383)
==3627== by 0x5315B90: intelSetTexBuffer2 (intel_tex_image.c:742)
==3627== by 0x46B02D6: __glXBindTexImageEXT (glxcmds.c:2639)
==3627== by 0x463A668: clutter_glx_texture_pixmap_update_area (clutter-glx-texture-pixmap.c:798)
==3627== by 0x463AD0C: create_cogl_texture (clutter-glx-texture-pixmap.c:375)
==3627== by 0x463B184: clutter_glx_texture_pixmap_notify (clutter-glx-texture-pixmap.c:729)
==3627== by 0x491DABB: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531)

I ran valgrind using the following commandline and then used the software X compositing that does not leak and compared the results:
G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-modules valgrind --leak-check=full --track-origins=yes --leak-resolution=high --show-reachable=yes -v --suppressions=gtk.suppression ./simple

The build and running instructions are in the comments of the example.