Re: [Evolution-hackers] Handy GObject debugging trick

[Milan Crha <mcrha redhat com>]

On Thu, 2011-03-10 at 13:42 +0000, David Woodhouse wrote:
> Are we not *ever* closing a folder, after the UI has visited it once?

	Hi,
CamelStore keeps list of opened folders in its bag-container, and
because there are caches of CamelStore-s which are not freed properly,
then neither folders are freed as ought to be. Did you ever notice a
flash in the folder tree when you change something in the account
preferences, but those changes were not propagated till next start? I
believe it's a side-effect of such CamelStore caches issue in evo
itself.

> No wonder Evolution tends to grow until it's eating all the memory in my
> system... :)

Well, it depends. There were some bugs fixed already (in 2.91.91), but
many are still there which no-one is aware of, I'm sure of that.

Two most significant I recall right now:
a) any attachments shown in the message preview were never freed,
together with its content - so with large attachments memory usage could
grow pretty quickly
b) the templates plugin used to leak folder infos when building menu
options for itself. It's not much leaking in a byte-size, but as the
menu is regenerated on each click/move/change in the message list, then
this can grow in time also quite quickly.

Thinking of Matt's change, I wrote something similar recently too, not
that sophisticated, and it did slightly different things too, but it did
what I wanted from it as well. Mine change was for pointer tracking.
Simple routines to track and untrack concrete pointer (usually track a
pointer in its init method and untrack it in its finalize method), and
list left pointers when exiting the application. I thought I'll add it
to Camel, but then I realized it's not about Camel only, so it could
come to e-data-server-util.h/.c, but then I couldn't decide, so I simply
dropped it. Maybe it would be useful for debugging purposes too. It was
for me. 
	Bye,
	Milan