Bug 119273

Created attachment 51066 [details]
day 1

Created attachment 51067 [details]
day 2

Created attachment 51068 [details]
day 3

You don't see all three until day 3. But from then on, all three will continue
to increase.

By the same logic, the leak could be in glibc.  There's no real indication here
that there is one underlying memory leak, let alone one in gtk; it could just as
easily be three different memory leaks (with each application leaking in its own
special way, which is entirely possible).  It's worth bearing in mind that some
applications have a larger memory footprint not because they're failing to free
memory when they're done with it (which is how I'd describe a leak) but because
they're retaining more state over time than they did previously (which may be
suboptimal but which is not technically a leak).

My understanding is that Mono has some well-known issues with how it does
garbage collection such that garbage-collected memory is not returned to the
system.  This is bad for long-running processes (e.g. beagled).  I think beagled
restarts itself at intervals to get around this, which is why it was using less
memory on day 3 than on day 2.  

Evolution's memory footprint can increase over time, especially with activity,
but I suspect much of that is due to various types of caching.  I can't rule out
the possibility of leaks, but I have no reason to believe any such leaks are in gtk.

I wouldn't be surprised if gtik2-applet2 was leaking (it looks probable), but I
have no reason to believe any such leaks are in gtk.  More likely, it's not
freeing memory when prices are updated.  We'd need valgrind logs to know for sure.

I'd suggest the following for future "memory leak" bug reports:

- valgrind logs *or*
- clear reference to leaked memory in the source code, ideally with patches

Also, the output of top(1) is generally easier to read in a bug report than
screenshots which open in different windows.