After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 620815 - Memory leaks with Evolution
Memory leaks with Evolution
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
2.30.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2010-06-07 09:48 UTC by Milan Crha
Modified: 2010-08-31 09:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First run under valgrind (276.05 KB, application/x-bzip2)
2010-06-22 12:27 UTC, Bojan Smojver
  Details
Run under valgrind with debuginfos (447.71 KB, application/x-bzip2)
2010-06-24 09:58 UTC, Bojan Smojver
  Details
Run under valgrind with debuginfos that resulted in a crash (482.55 KB, application/x-bzip2)
2010-06-24 09:59 UTC, Bojan Smojver
  Details
eds patch (1.71 KB, patch)
2010-06-24 18:10 UTC, Milan Crha
committed Details | Review
evo patch (6.62 KB, patch)
2010-06-24 18:11 UTC, Milan Crha
committed Details | Review
eex patch (2.38 KB, patch)
2010-06-24 18:23 UTC, Milan Crha
committed Details | Review

Description Milan Crha 2010-06-07 09:48:25 UTC
Forwarding this from downstream bug report
https://bugzilla.redhat.com/show_bug.cgi?id=568693

Description of problem:

evolution leaks memory. On my x86_64 Fedora 12 box I have found a few time now
that all the memory have gone away cause the machine to swap.

What appears to happen is after evolution is exited it is not really exiting
and leaves evolution processes running. These processes over 12 hours use all
of my 8gigs and good part of the 6 gig of swap. Killing the process with kill
frees all memory back to the system.  

Version-Release number of selected component (if applicable):

evolution-data-server-doc-2.28.2-1.fc12.noarch
evolution-help-2.28.2-1.fc12.noarch
evolution-data-server-2.28.2-1.fc12.x86_64
evolution-2.28.2-1.fc12.x86_64
evolution-data-server-devel-2.28.2-1.fc12.x86_64

How reproducible:

Seems to do it randomly, unable to trigger it. 

Steps to Reproduce:
1. Run evolution
2. Do normal email stuff i.e. read email and send email.
3. Quit evolution
4. Check to see if it has really quit, if not watch memory slowly leak away. 

Actual results:

Large memory leak.

Expected results:

No memory leak.

Additional info:

Let me know of any information I can gather to help fix this.

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

Using IMAP accounts with all mail stored on server.

Will install debug packages and try and catch it. 

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

Downstream bug report contains a valgrind log for F12 (evolution 2.28), but other user reported similar issue with F13 (evolution 2.30).
Comment 1 Bojan Smojver 2010-06-22 12:27:10 UTC
Created attachment 164298 [details]
First run under valgrind

I only ran this or a while, so we may not have gotten much. It is very, very slow.
Comment 2 Milan Crha 2010-06-24 07:22:38 UTC
Thanks for the update, Bojan. The good news is that the log shows quite much memory being lost in evolution-exchange:
> 3,060,917 bytes in 16,307 blocks are definitely lost in loss...
>    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
>    by 0x4200284: g_malloc (in /lib/libglib-2.0.so.0.2400.1)
>    by 0x4219069: g_strdup (in /lib/libglib-2.0.so.0.2400.1)
>    by 0x5F0128F: ??? (in /usr/lib/evolution-data-server-1.2/camel-providers
>          /libcamelexchange.so)
>    by 0x4B08572: ??? (in /usr/lib/libcamel-provider-1.2.so.14.0.1)
>    by 0x5E22D2F: sqlite3_exec (in /usr/lib/libsqlite3.so.0.8.6)
>    by 0x4971CE6: camel_db_select (in /usr/lib/libcamel-1.2.so.14.0.1)
>    by 0x4971FDC: camel_db_read_message_info_record_with_uid (in /usr/lib
>          /libcamel-1.2.so.14.0.1)
>    by 0x4B093B9: ??? (in /usr/lib/libcamel-provider-1.2.so.14.0.1)
>    by 0x4B02596: camel_folder_summary_uid (in /usr/lib/libcamel-provider-
>          1.2.so.14.0.1)
>    by 0x4B025FB: camel_folder_summary_index (in /usr/lib/libcamel-provider-
>          1.2.so.14.0.1)
>    by 0x5EFB119: camel_exchange_folder_construct (in /usr/lib/evolution-
>          data-server-1.2/camel-providers/libcamelexchange.so)

though the bad news is that it miss some debug information to replace those ??? entries in the above trace. Could you install debuginfo packages for evolution-data-server, evolution, evolution-exchange and re-run it please? It's OK to run it just for few minutes, because as you said, evolution is awfully slow when running under valgrind. By the way, what version of evolution are you running? I hope it's 2.30.x, as there is not planned any update for 2.28.x. Please also note that there had been done some fixes with reference counting on CamelMessageInfo and their freeing in 2.31.x, thus those possibly lost involving these might also be fixed in there.
Comment 3 Bojan Smojver 2010-06-24 08:54:25 UTC
OK, shall do. I'm running whatever is the latest in F-13, which is evolution-2.30.1-8.fc13.i686 right now.
Comment 4 Bojan Smojver 2010-06-24 09:58:39 UTC
Created attachment 164485 [details]
Run under valgrind with debuginfos
Comment 5 Bojan Smojver 2010-06-24 09:59:20 UTC
Created attachment 164486 [details]
Run under valgrind with debuginfos that resulted in a crash
Comment 6 Milan Crha 2010-06-24 18:08:54 UTC
Thanks for the update. I'm about to attach patches for those "definitely lost", as they are those which may be freed but aren't. Those "possible lost" usually means memory stored in some cache, global variable, thus those I left as they are. I didn't fix all definitely lost, though, as some were from pango, and some I didn't understand. Anyway, those most leaking are fixed.

I noticed you was able to invoke many parts of Evolution while under valgrind, which I appreciate. Thanks for your help with this.
Comment 7 Milan Crha 2010-06-24 18:10:11 UTC
Created attachment 164536 [details] [review]
eds patch

for evolution-data-server;

This one is small.
Comment 8 Milan Crha 2010-06-24 18:11:45 UTC
Created attachment 164537 [details] [review]
evo patch

for evolution;

Slightly larger, but still not for the most leaking part, which comes from eex.
Comment 9 Milan Crha 2010-06-24 18:23:09 UTC
Created attachment 164538 [details] [review]
eex patch

for evolution-exchange;

And finally eex, our culprit.
Comment 10 Milan Crha 2010-06-24 18:47:56 UTC
Created commit 4b9c37c in eds master (2.31.4+)
Created commit 179db75 in evo master (2.31.4+)
Created commit af5483d in eex master (2.31.4+)

Created commit 488a8ee in eex gnome-2-30 (2.30.3+)

Though the above patches are for gnome-2-30 branch, and not everything applies to actual master, then I committed only the evolution-exchange part to gnome-2-30 branch, because there will be only one update for the stable, and it would be quite bad to break Evolution with this, in case I overlooked something. We have everything in master, so if I really overlooked, then we'll notice that, I hope soon.
Comment 11 Bojan Smojver 2010-06-25 04:24:09 UTC
It's a bummer this isn't going to be in 2.30.2 :-(
Comment 12 Bojan Smojver 2010-07-01 23:44:17 UTC
Any chance of applying some of the patches to Evo in F-13? This morning I found Evo (2.30.2) using 451 MB of RES memory. This VM has only 1 GB...
Comment 13 Bojan Smojver 2010-08-31 07:09:09 UTC
Running .3 on F-13 now. Using 168 MB RES. So, looks like there is still leaks in that branch. Let's hope .32 series will be better.
Comment 14 Milan Crha 2010-08-31 09:31:48 UTC
Yes, it will be better. There is an initiative to fix more leaks, see 
https://bugzilla.gnome.org/showdependencytree.cgi?id=627707