[cairo] Memory leaks in cairomm

[Murray Cumming]

>> On 6/12/06, Rodrigo Rivas <rodrigorivascosta at gmail.com> wrote:
> [snip]
>>>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.
>
> Well spotted. It's much better to know about this now than after we've
> frozen the API/ABI.
>
> By the way, the only reason that we'd want the C++ wrapper object to live
> longer than any of our RefPtrs to it is in case the underlying C object
> (that may continue to be used by the underlying C Cairo library) is
> delegating something to the wrapper.
>
> In gtkmm, that means default signal handlers and other virtual function
> overrides. But I don't think there's anything like that in cairo yet. I
> don't think there's even any callbacks, which C++ would wrap to virtual
> methods.

Furthermore, if there ever is any Cairo callback-based API like this in
the future:
- I would want to avoid wrapping it via a virtual function, to avoid
increased code size.
- We could use a regular sigc::slot instead, and advise that it should not
be a member method of a derived class, or otherwise use member data/state
of the C++ wrapper instance, because the C++ wrapper instance could be
destroyed before the underlying C instance.

So, I'm leaning towards the keep-a-second-refcount idea below. It's kind
of ugly, but it's a lot nicer than dealing with what-died-first and
stay-alive-until-it-dies problems that we have to deal with in gtkmm.

> So maybe we could decide to delete our C++ wrapper as soon as the last
> RefPtr is gone. We could use a second refcount, or maybe this version of
> the RefPtr would be useful. It only references the C object once, and then
> acts like a non-intrusive sharedptr. I was never brave enough to risk
> replacing Glib::RefPtr with it for gtkmm:
> http://bugzilla.gnome.org/show_bug.cgi?id=104332
>
> I also need to get around to adding a sharedptr for the implementation of
> Path:
> http://lists.freedesktop.org/archives/cairo/2006-May/006907.html
> Maybe that's something we could reuse.
>
> Murray Cumming
> murrayc at murrayc.com
> www.murrayc.com
> www.openismus.com
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>


Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com