[cairo] Memory leaks in cairomm

Jonathon Jongsma jonathon.jongsma at gmail.com
Mon Jun 12 20:06:33 PDT 2006


On 6/12/06, Rodrigo Rivas <rodrigorivascosta at gmail.com> wrote:
> I don't know if I'm missing something, but I've noted that the RefPtr
> implementation in cairomm leaks memory "always".
> That is because when you call, say Surface::create(...), it calls
> basically "new Surface(cairo_surface_create_linear(...))" and returns
> the new pointer wrapped into a RefPtr<Surface>. The ~RefPtr decrements
> the ref-counter of the cairo_surface_t object, but it <never> deletes
> the new'ed Surface object. It's same for every type in cairomm.

wow.  yeah, that's a problem.

> The glibmm's RefPtr doesn't leak! But that's because the
> Glib::ObjectBase class takes care of this, and gets notified when the
> wrapped object is destroyed.
> Also there are a few Glib classes that doesn't inherit from
> Glib::ObjectBase, such as Glib::Thread. Those are implemented simple
> as cast pointers to the underlying type (I'm not sure this is 100%
> portable, valid C++ code, but it will probably work as long as there
> is no virtual functions and no member variables).

This scares me a little bit.  It seems to be pretty limiting since it
basically precludes us from ever using a virtual function in the
future.

It would be helpful if there were a way of determining whether the
reference count of the underlying object has reached zero and is
destroyed.  For a cairo_t, destroying the object doesn't set the cr
pointer to NULL.  Does anybody know whether there is any other way of
determining whether an underlying object has been destroyed?

Thanks,
Jonner


More information about the cairo mailing list