[Xcb] [PATCH 6/7] Don't leak reply data.

[Julien Danjou]

On Thu, Mar 08 2012, Alex Plotnick wrote:

> It certainly wasn't obvious to me. The basic issue is that data returned
> by XCB in the reply needs to be freed eventually. The old code was never
> doing that, since a buffer object created using PyBuffer_FromMemory
> never calls free on the supplied pointer, even when its refcount drops
> to 0. A buffer created with PyBuffer_New, however, does. So with this
> patch, we copy the reply data into such a buffer object, then free the
> original. When the buffer object's refcount goes to 0, its copy of the
> repy data will be deallocated for us.

Ok, got it. I'm annoyed that this remove the nice zero-copy method, but
OTOH IIUC there's no other solution since a function is called with shim
as argument, it can be referenced and therefore we can't free(data) just
after.

I've pushed the patch. :)

> I suppose I should preemptively explain just a bit more about that patch,
> while I'm thinking about it. Buffer objects can be "chained": you can use
> one buffer object as the parent of another, and they'll share storage.
> The problem was that the generated code was creating buffer objects that
> used themselves as their parent, creating cycles. Such objects never
> have a refcount of 0, and so were never being deallocated. (Python has
> a proper garbage collector, but it requires hooks at the C level, and
> buffer objects aren't GC-aware.) My patch changes it so that a proper
> parent object (i.e., not self) is used in all cases, thus eliminating
> the cycles and letting the reference counter do its job.
>
> Let me know if there are issues that are still unclear.

I didn't had the time to review this patch, but for the explanation,
that will help me to do it faster. :)

-- 
           Julien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20120309/f110389b/attachment.pgp>