glBufferData issue.

I was doing a valgrind test on gnome-shell.
Part of it was:

==11487== 2,771,578 bytes in 6 blocks are possibly lost in loss record 34,261 of 34,265
==11487==    at 0x4C2AF1F: malloc (in /usr/lib/valgrind/
==11487==    by 0x1C7A6FD8: ??? (in /usr/lib/
==11487==    by 0x1DCD0036: ??? (in /usr/lib/
==11487==    by 0x1DCBD23C: ??? (in /usr/lib/
==11487==    by 0x1D922428: ??? (in /usr/lib/
==11487==    by 0x1D924115: ??? (in /usr/lib/
==11487==    by 0x969A3BC: recreate_store (cogl-buffer-gl.c:154)
==11487==    by 0x969A78A: _cogl_buffer_gl_map_range (cogl-buffer-gl.c:274)
==11487==    by 0x96B21A6: cogl_buffer_map_range (cogl-buffer.c:263)
==11487==    by 0x96B22C0: cogl_buffer_map (cogl-buffer.c:241)
==11487==    by 0x68E2AE4: clutter_canvas_emit_draw (clutter-canvas.c:440)
==11487==    by 0x68E2AE4: clutter_canvas_invalidate (clutter-canvas.c:513)
==11487==    by 0x68E9D30: clutter_content_invalidate (clutter-content.c:176)

which I showed to a Gnome developer.
He said:

So this seems to be an issue with NVIDIA’s OpenGL implementation.
Perhaps someone can take a look?
Thank you.

I don’t know that this is really a memory leak. Does the amount of “leaked” data increase if you call glBufferData more times? It’s possible this is just cached memory inside the driver.

I will try to find that out. Thank you very much.