GNOME Bugzilla – Bug 622366
evolution eats 1.5GB memory after one day, leaking?
Last modified: 2011-06-02 05:29:40 UTC
I am using evolution-2.28.2 on SLED11-SP1-x86_64. The memory usage is growing all the day, even during night. I have to restart it every day. I receive mails from three servers using imap, groupwise, and pop3. I currently have about 1.3GB of mails on the imap server. I use evolution to filter mails from groupwise and pop3 and move them to the imap server. The memory usage after half a half hour is PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5692 pmladek 20 0 904m 264m 28m S 0 6.7 0:21.50 evolution.bin The memory usage after 24 hours is PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5141 pmladek 20 0 2232m 1.5g 24m S 1 38.5 8:57.22 evolution.bin Please, let me know if you need more information.
valgrind logs to identify potential memory leaks are welcome.
Created attachment 164635 [details] valgrind log; evolution running about 30 minutes; wrote one mail; read some mails; checked few folders I am sorry for the delay. This was incredibly crazy week. I have vacation the following two weeks. I will try to provide better valgring log then (more debuginfo packages, keep it running over night).
Hi Petr; thanks for the log - unfortunately, it doesn't have the data we would like, can you: ==16494== Rerun with --leak-check=full to see details of leaked memory so we can get some stack frames of the culprits ? :-) Thanks.
Petr, try disabling all plugins with command line switch and test with that.
Created attachment 166692 [details] valgrind log with --leak-check=full I am sorry for the delay. I had vacation... This time evolution was running over night with valgrind --leak-check=full. --disable-eplugin did not help. It still ate too much memory when running many hours time.
ah - wow :-) what a good trace. Unfortunately, you didn't have evolution-data-server-debuginfo installed - so the traces are fragmentary; but interesting nonetheless. Things like: ==7256== 57,578,249 bytes in 730,337 blocks are definitely lost in loss record 20,789 of 20,790 ==7256== at 0x4C261D7: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==7256== by 0x11C28AD2: g_malloc (in /usr/lib64/libglib-2.0.so.0.2200.5) ==7256== by 0x11C406CD: g_strdup (in /usr/lib64/libglib-2.0.so.0.2200.5) ==7256== by 0x1CF1EF42: soup_soap_parameter_get_string_value (in /usr/lib64/libegroupwise-1.2.so.13.0.1) ==7256== by 0x1CF09A57: e_gw_connection_get_all_mail_uids (in /usr/lib64/libegroupwise-1.2.so.13.0.1) ==7256== by 0x24663469: ??? (in /usr/lib64/evolution-data-server-1.2/camel-providers/libcamelgroupwise.so) are really good to catch :-)
Ok - the leak above seems to be in: camel/providers/groupwise/camel-groupwise-folder.c (gw_update_all_items) which removes items from item_list - by deleting links - without freeing the associated (duplicated) uid - so I guess we leak this UID there; should save some MB over time: diff --git a/camel/providers/groupwise/camel-groupwise-folder.c b/camel/providers/groupwise/camel-groupwise-folder.c index c5bf64d..8a73189 100644 --- a/camel/providers/groupwise/camel-groupwise-folder.c +++ b/camel/providers/groupwise/camel-groupwise-folder.c @@ -2418,6 +2418,7 @@ gw_update_all_items (CamelFolder *folder, GList *item_list, GError **error) camel_folder_change_info_remove_uid (changes, uid); CAMEL_GROUPWISE_FOLDER_REC_UNLOCK (folder, cache_lock); } else { + g_free (temp->data); item_list = g_list_delete_link (item_list, temp); } index++; I've committed to master - but it needs testing & back-porting to previous versions.
Another MB of un-freed responses - again on master, needs back-porting. --- a/servers/groupwise/e-gw-connection.c +++ b/servers/groupwise/e-gw-connection.c @@ -840,9 +840,11 @@ e_gw_connection_get_container (EGwConnection *cnc, const gchar * uid) subparam = soup_soap_response_get_first_parameter_by_name (response, "folder"); container = e_gw_container_new_from_soap_parameter (subparam); + g_object_unref (response); return container; } + g_object_unref (response); return NULL; }
Add me to cc, Groupwise leaks are very helpful to us.
Should I provide (In reply to comment #6) > Unfortunately, you didn't have evolution-data-server-debuginfo installed - so > the traces are fragmentary; but interesting nonetheless. Should I generate another trace with the debuginfo package installed?
Created attachment 167167 [details] valgrind log with --leak-check=full and evolution-data-server-debuginfo Evolution was running half an hour this time.
The two patches above (committed to master) fix a large number of Well - it looks like gtkhtml is leaking somewhat; and that needs addressing in master and back-porting. It is also probable that we are leaking CamelFolder references somewhere - that is the bulk of the leakage you report (unrelated to groupwise - just using IMAP). Unfortunately, such leaks are incredibly hard to track down. Matthew - after your de-bonobo-ification, and camel re-working; are you looking at reference count leaks ? Do we have some built-in debug / reference tracking of what is left un-freed when we exit Evolution normally ? [ it took weeks to free the original Evo of such reference leaks with that in-place ]. I'm also worried that the lifecycle / reference web is weakening ;-) which is of concern.
(In reply to comment #12) > Matthew - after your de-bonobo-ification, and camel re-working; are you looking > at reference count leaks ? Do we have some built-in debug / reference tracking > of what is left un-freed when we exit Evolution normally ? [ it took weeks to > free the original Evo of such reference leaks with that in-place ]. I haven't really looked at reference count leaks for quite awhile, but I can do so again. There's nothing in Evo itself -- I usually just rely on GObject's rudimentary tools: GOBJECT_DEBUG=objects I had an equally rudimentary enhancement proposal to show even more data at exit, but it never really went anywhere: https://bugzilla.gnome.org/show_bug.cgi?id=354457 And that evolved into some fancy dtrace/systemtap integration which is apparently in GLib now but I've never played with it: https://bugzilla.gnome.org/show_bug.cgi?id=606044
See also: http://blogs.gnome.org/alexl/2010/01/04/tracing-glib/
There were even more common leak fixes done on master, included in 2.91.91. Could you retest with that version, please? It should behave more sanely.
Any intentions to fix this for Ubuntu 11.04 ? It is really awful to have to restart Evolution every 5 or 6 hours to free memory .
Jose, can you please file a bug in Ubuntu launchpad and let them know the upstream bug id so they can pick patch from here. Please feel free to open a new bug with valgrind trace if the problem still occurs with a newer version of Evolution 3.0.1 or later, thanks.