[[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? _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
