IMAP only or does the reporter have other types of accounts?  In particular, NNTP is known to chew up mass quantities of RAM with large newsgroup lists.

Created attachment 124846 [details]
process information over time from evolution

I killed evolution at the end, else the system would became unresponsible due to permanent swapping.

Additional information for the last posting:

I have got evolution-data-server 2.22.3-0ubuntu2 and evolution 2.22.3.1-0ubunut1 installed. I am using IMAP with several folders. The system is

Linux tttdal 2.6.24-22-generic #1 SMP Mon Nov 24 19:35:06 UTC 2008 x86_64 GNU/Linux

When moving several mails at once from one folder to another (by selecting them first and moving them by dragging them to the destination folder) it happens often that the "evolution --mail" process eating up the whole system memory in a couple of seconds.

The behavior is reproducable. However it does not happen always when moving several messages, just with particular combinations. I think it also happen when moving a message while evolution is already connected to the IMAP server checking for new mail.

(In reply to comment #1)
> IMAP only or does the reporter have other types of accounts?  In particular,
> NNTP is known to chew up mass quantities of RAM with large newsgroup lists.

IMAP only, actually two IMAP accounts, one living on a Zimbra server, the other on a cyrus IMAP deamon. Plus, a calendar subscription via .ics URL on the Zimbra server.

Would it help to generate a valgrind log including all the still reachable memory?

yes, valgrind logs could help to track this down

Same issue here, since i upgraded to 2.24.2 (ubuntu 8.10). Just that it takes less time for evolution to eat up > 2Gb of memory, and trash my box -- if i don't kill it fast enough. Unfortunately this bug renders evolution pretty useless to me.

I'm also using IMAP, and have 100s of thousands of email (many years accumulated).

Strangely it starts eating up memory even in the background, when i'm not using evolution. I'm not sure what triggers it, but once it starts, i can see it eating up memory at a few megs per second.

Running valgrind (with Memcheck) tells me that most of the memory was correctly returned.

So I ran valgrind --tool=massif to get a heap profile, the result is attached.

sorry, the file didn't fit the attachment, so i put it here:

http://abstract.homelinux.org:9240/janpf/massif.out.22136

(pls, if someone with more permissions could copy it over and add as an
attachment, it would be great, as that is a temporary space, it has 1.4mb of
text file)

to pretty print the massif output use:

$ ms_print massif.out.22136 | less

look at the last snapshot (end of this output) to have an idea which functions
allocated most of the space.

thx

- jan

Created attachment 125552 [details]
valgrind --tool=massif output

uncompress and use ms_print massif.out.22136 to see pretty print version

Yes I happens with my too.

I don't have the possibility to valgrind on my eeepc.

But as far as I can determine e-d-s allocated 8MB blocks every few minutes. This happens even after I close Evolution - as e-d-s stays in the background.

After some ours 200MB is allocated to e-d-s and everything starts becoming sloooow. And then I need to kill e-d-s.

I have imap, caldav and ldap. Memory consumption does not seem to increase extra when I actively use caldav or ldap.

Guess it is imap related as suggested above.

Ferry

> I don't have the possibility to valgrind on my eeepc.

Why not?

(In reply to comment #9)
> But as far as I can determine e-d-s allocated 8MB blocks every few minutes.
> This happens even after I close Evolution - as e-d-s stays in the background.
> 
> After some ours 200MB is allocated to e-d-s and everything starts becoming
> sloooow. And then I need to kill e-d-s.
> 
> I have imap, caldav and ldap. Memory consumption does not seem to increase
> extra when I actively use caldav or ldap.
> 
> Guess it is imap related as suggested above.

Well, except that IMAP isn't handled by the e-d-s process.
That memory gets flushed when you close Evolution.

I also have the problem in my eee pc (besides my desktop as reported above). 

But when i kill evolution most of the memory returns -- no need to kill e-d-s.

Btw, by looking at the valgrind output i sent (the massif memory profile), i understand most of the memory is being consumed by the IMAP module.

cheers
- jan

Well, I use KDE sysguard (debian) or gnomes equivalent (ubuntu) and see evolution-data-server-2.22 (or 2.24) sitting there, even after quitting evolution. Allocated memory by e-d-s does not change - actually continues to increase even with evolution closed.

Ferry

Interesting, since i upgraded to evolution 2.24.3 (current version in ubuntu 8.10) evolution stopped leaking memory like crazy, so i thought the problem was over.

but now that evolution is able to stay alive for more than a few minutes, i finally see the problem others were describing here: after a couple of days e-d-s is consuming several Gb of memory.

later i'll run valgrind on it and post the results here.

With respect to leaking evolution-data-server, while using CalDAV,
see bug #573187, the fix will be included in 2.26.1.

With respect to evolution itself, it's a different story.
Some valgrind --leak-check=full on 2.26.0 Evolution would help here.

Looks like my issue might be addressed by bug #573187 but I am not sure if this has been made available as an update to 2.24?

No, it has been only committed to trunk and there won't be any commits to the old stable version.
You could ask your vendor to ship an updated 2.24 version.

Is anybody of you able to run evolution on some real user data with a valgrind as requested in comment #15, on a version 2.26.1+, to check the leaking state of it, please? Thanks in advance.

I guess it's another problem because this bug is too old, but it happens again with e-d-s from git master(6344fa54e518041b285320841873f47b8d413206). It doesn't always happen though, which makes it even harder to debug. 

btw, I don't use IMAP, so this definetely looks like a different issue, I can file a separate bug report if you want. 

Hi Carlos, nope, let's use this bug report. Just note that eds can leak mainly with your address books and/or calendars. What kinds of these are you using, please? Maybe the leakage depends on the fetching of updates from a remote machine, I do not know. Could you try to run eds under valgrind and see whether it'll happen for you with it, please? I think about something like:
a) close evolution
b) evolution --force-shutdown
c) on one console:
   valgrind --leak-check=full /path/to/your/evolution-data-server-2.28 &>v.log
d) on other console run: evolution
then let it run for some time, I do not know for how long, just try some usual operations and after that close evolution and do:
e) pkill -QUIT evolution-alarm
   or some similar kill -QUIT of the evolution-alarm-notify process.
It should ideally close evolution-data-server in other few seconds. If not, just Ctrl+C it and let valgrind do its job. Thanks in advance.

Hey Carlos, did you get time to collect valgrind traces ?

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!

Created attachment 154306 [details]
Valgrind log of evolution-data-server-2.28

This is a log taken from an amd64 Ubuntu Karmic machine, as requested in the message thread.

I hope this is enough information for you guys, Milan and Akhil.

Sorry about compressing it; it was too big to upload otherwise.

I've taken it on my Karmic amd64 machine as described in your instructions, Milan. I hope it sheds some light. I stopped logging when Evolution stopped responding, and I don't really know how to read the log, but believe me, had I let it run longer, it would've eaten my memory. I have 4 GB RAM and after an hour or so, evolution-data-server-2.28 eats about 2 GB.

Again, I hope this helps.

Thanks, looking forward to seeing this bug reopened!

Varun

Created attachment 154377 [details] [review]
eds patch

for evolution-data-server;

For the definitely lost memory in the above valgrind log. Those "still reachable" memory pointers are most often correct pointers, some caches.

Thanks for the update. Could you install debug info package for evolution-data-server, please? It' seems it's not installed, as there are lines like this
> ??? (in /usr/lib/evolution-data-server-1.2/extensions/libebookbackendfile.so)
which means it doesn't know the source information.

> ==6582== LEAK SUMMARY:
> ==6582==    definitely lost: 15,247,940 bytes in 3,414 blocks
> ==6582==    indirectly lost: 2,480 bytes in 13 blocks
> ==6582==      possibly lost: 3,500,857 bytes in 28,024 blocks
> ==6582==    still reachable: 382,087 bytes in 3,853 blocks
> ==6582==         suppressed: 0 bytes in 0 blocks

See from the leak summary it was using slightly less than 20MB of memory, why is the rest of eds memory eating so high I do not know, maybe the valgrind was using it to track all the pointers.

I hope I was able to cover most of the leaks with the above patch, though with the debug info packages and source lines it would be more clear.

-------------------------------------------------------------------------

Created commit fd5c2d8 in eds master (2.29.91+)
Created commit bd5527d in eds gnome-2-28 (2.28.3+)

Hi all,

I've managed to figure out WHAT was causing the memory leak in eds.

It was happening to me when Pidgin's Evolution Integration plugin was enabled, and Pidgin was running. As soon as I turned off that plugin (or Pidgin itself), eds settled into about 8 megs of usage and didn't waver even a kilobyte for over two days of staying on and active.

NOTE: I didn't even have any accounts selected to synchronize with Evolution; the plugin was simply enabled. It was obviously querying eds without actually sending any "useful" information (at least in my eyes).

I still believe it could be a bug in eds, since the memory leak does happen with eds and not Pidgin.

I've installed the dbg package for eds and am reloading the plugin right now in order to reproduce the initial conditions that caused the memory leak. I will attach the valgrind log shortly.

Thanks!

Varun

I'm attaching the valgrind log in a sec...just want to point out that my terminal window that is running Evolution has these statements when that Evolution plugin is enabled in Pidgin:

bbdb: Buddy list has changed since last sync.
bbdb: Synchronizing buddy list to contacts...
bbdb: Done syncing buddy list to contacts.
bbdb: Buddy list has changed since last sync.
bbdb: Synchronizing buddy list to contacts...

So it's doing that repeatedly, and I think eds is just not freeing up memory afterwards. Is that plausible guys?

Thanks, attaching new Valgrind log now. I hope I installed the right packages for the log to be more useful.

Varun

Created attachment 154442 [details]
New Evolution Valgrind log with evolution-data-server-dbg package installed.

Same machine as before: amd64 Ubuntu Karmic.

Again, this memory leak is easily reproducible by enabling Pidgin's "Evolution Integration" plugin. There is no need to configure any options (or any accounts to actually synchronize with Evolution), simply enabling the plugin will cause eds to slowly begin chewing memory.

When evolution is run in the terminal, I can see that it's trying to synchronize buddy list with Evolution contacts a fair amount.

Does anyone know if the upstream Pidgin plugin author is aware of this?