Re: [Evolution-hackers] Beware of GtkTreeRowReference

[Matthew Barnes <mbarnes redhat com>]

[[I'm CC'ing the hackers list.]]

On Wed, 2011-03-02 at 14:00 +0100, Milan Crha wrote:
> The GtkTreeRowReference is adding a reference count to the model, so if
> you store this GtkTreeRowReference inside model itself, then the model
> is never freed. This is a case for EAttachmentStore, if it has some
> attachments, then it's never freed, same as the inner object and the
> CamelMimePart and god knows what else. That might explain increasing
> memory usage in evolution when have run it for few hours. I'm finishing
> a patch for this in git master, it's under testing right now, but I
> wanted to warn you, because this circular dependency is not obvious on
> the first look. Please avoid similar approaches in the future.
> 
> I'm not removing this GtkTreeRowReference from the EAttachment, I'm only
> making sure when the object whom created EAttachmentStore also removes
> all attachments before it unrefs the store itself - basically because
> it's too late for any bigger kick into sources.

Huh, thanks for the tip.  That's probably an issue in several other
places in Evolution and libedataserverui then.

Whenever I subclass GtkListStore or GtkTreeStore I usually build an
internal index of whatever would be the primary key in the store, and I
do that with a hash table of GtkTreeRowReferences.

Does GtkTreeRowReference drop its model reference when the row is
removed?  If so, it ought to be sufficient to clear the model with
gtk_list_store_clear() or gtk_tree_store_clear() before unreffing it.
Is that what you're doing?