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

[Alex Plotnick]

At or around Thu, 08 Mar 2012 16:30:33 +0100, Julien Danjou said:

> Could you explain this patch? It's probably obvious, but I just don't
> see what's the problem is. :)

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.

When I found this, I thought that it was the source of the leak that had
been discussed on this list in July 2011. It turns out that it was *one*
of the sources of that leak; the other was more subtle, and is fixed by
the 7th patch I sent ("Avoid reference cycles in response instances").

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.

Thanks,

	-- Alex