GNOME Bugzilla – Bug 510949
Evolution data server : Severe memory leak
Last modified: 2008-08-18 08:48:15 UTC
Evolution 2.21.90 First, i am explaining what operations i did.I started evolution , composed a mail ,sent it and then left evolution running for whole night and next day also.When i came back evolution was still running but evolution-data-server had been killed long back , i guess. Here is the output of gnome-terminal where i started evolution-data-server process separately (evolution-data-server-2.22:5413): libedata-book-WARNING **: error while reading summary item libedata-book-Message: Flushed summary to disk (evolution-data-server-2.22:5413): GLib-CRITICAL **: g_ascii_strcasecmp: assertion `s1 != NULL' failed in server_log_handler (evolution-data-server-2.22:5413): GLib-CRITICAL **: g_base64_decode: assertion `input_length > 1' failed in server_log_handler error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer GLib-ERROR **: gmem.c:135: failed to allocate 1021417 bytes aborting... I had observed eds memory consumption for an one and half hours before leaving my machine and collected Residential memory consumption details. (*Important Note* : I have 2 GB RAM in my system and Evolution was connected to Group wise server during my observation. Group wise server is our test set up so there was no traffic of mails / calendar events during whole observation). Details : S.No. | Operation | Residential Memory of EDS (MB) | Time(PM) | | | 1. Started evolution 95 2. Auto completed during 100 composition 3. Typed contents of mail 120 7:27 and sent 4. Idle 135 7:45 5. Idle 144 7:57 6. Idle 161 8:17 7. Idle 171 8:27 8. Idle 183 8:44 9. Idle 195 8:46 10. Idle 202 8:56 Then i left my system on and when i came back after 2 days , eds had been killed due to unavailable memory.
Created attachment 103304 [details] Valgind traces of evolution-data-server process
I have both glib and libsoup packages updated. IMHO blocker but i will wait if anyone observes before raising severity.
If it happens, then it is a blocker. I'm trying it anways.
Created attachment 103318 [details] Valgind traces of evolution-data-server process Operations when valgrind traces were taken - started evolution,sent mail and left idle.Memory consumption for eds process reached upto 230 MB (residential memory) in an one hour.
Dan, seems like libsoup has quite a lot of leak in this. Can you just have a look at this?
Created attachment 104105 [details] [review] Fix for some leaks in EDS
Sorry, I didn't notice when I got cc:ed on this bug before! (In reply to comment #5) > Dan, seems like libsoup has quite a lot of leak in this. Can you just have a > look at this? It looks like all of the libsoup-related leakage* is within gnutls, and marked "still reachable", not "definitely lost" or "possibly lost". This probably means that there was one or more SSL connections open when you quit, and valgrind is reporting all of the state gnutls is keeping for those connections. If you want a more accurate report, you'll need to make sure that (a) the backend is getting shut down properly when evolution exits, and (b) the backend does: soup_session_abort (session); g_object_unref (session); when it is shut down. But even then, there will still be "still reachable" memory reported from call chains involving "gnutls_global_init", because libsoup never calls gnutls_global_deinit() at shutdown... [* Actually, there's one stack trace that mentions soup that isn't gnutls; the "123,491 bytes in 1,702 blocks are definitely lost" involving soup_soap_parameter_get_string_value(). But that looks like a bug in e_gw_item_new_from_soap_parameter(); it needs to free dist_type.]
Thanks Dan for the insights. Akhil, can you try this on a clean setup again? Just make sure that the account was enabled last time and quit everything and restart your testing. Chen, your is not much relevant here, but looks to fix quite a lot of leaks. Another set_attachment_list is pending in e-cal-backend-groupwise.c fix that also and commit.
Yes, will address the leak in *groupwise.c as well. I did not want to create another bug for attaching the leak fixes. Can we have a common bug to address all the memory leak issues across EDS if not this bug?
Created attachment 104577 [details] [review] eds patch (a little leak) for evolution-data-server; When I was looking on other bug, I found this and Chen said I can attach here, so I'm doing it. This is not so critical as the above, though.
Patch looks good to commit.
Created attachment 104633 [details] [review] Some more leak fixes.
Created attachment 104661 [details] [review] proposed (partial) eds patch for evolution-data-server; Last Chen's patch inspired me to look for leaks around soup_soap_parameter_get_string_value and here comes a patch, even GW related only.
Chen's first patch has been committed in revision 8465 by himself. My first patch committed to trunk. Committed revision 8466.
If I can review for Chen, then I think the patch is fine, but to have it even better, then you should check all calls to e_cal_backend_cache_get_component, I guess there will be couple of places with forgotten unref.
Chen, your patch looks fine and so you review Milan's patch ;-)
Have a look at bug 515744 also
Chen: Review Milan's patch fast. I need any leak fixes alteast a week testing.
neat patch. Please commit it.
Chen's patch committed to trunk. Committed revision 8514. My second patch committed to trunk. Committed revision 8515.
Bumping version to a stable release.
Created attachment 107508 [details] Valgrind traces of evolution-data-server process I have collected few more traces of eds (evolution 2.23.x) with group wise back end. EDS residential memory went up to 259 MB in an over night time period. I have closed evolution, there was no crash. Please discard if traces are similar to previous one.
Created attachment 109610 [details] Valgrind traces of evolution-data-server process I left evolution 2.23.1 running for 2 days/nights. I hadn't done any operation during 2 days. Before closing evolution, i did auto completion and switched among components and then forcefully closed evolution (no crash).
Created attachment 109618 [details] [review] proposed eds patch (another) for evolution-data-server; I skipped most of the "still reachable" entries in the last val grind output. I also noticed some problems around e_cal_component_set_attachment_list (and _get_ probably too). I do not know how this fix properly, let's wait what chen thinks, because the get_attachment_list function has very nice comment: /* FIXME : this ref count is screwed up * These structures are being leaked. */ I think I mentioned this somewhere already.
+ SOUP_MEMORY_TAKE, (const char *)body, len); + + xmlFree (body); Seems to cause a crash. + g_ptr_array_foreach (uid_array, (GFunc) g_free, NULL); g_ptr_array_free (uid_array, TRUE); Doesn the g_ptr_array_free statement free the data in the array also ?
(In reply to comment #25) > Doesn the g_ptr_array_free statement free the data in the array also ? It frees the array of pointers, but not what the pointers point to.
Have a look at bug 500509
chen, ping (Matt answered in comment #26) Akhil, I moved it as a duplicate of other bug, which contains a patch
Thanks Milan, i saw the patch some time back but couldn't able to find later :)
The patch can be committed removing the hunk which causes the crash.
Heavily modified patch committed to trunk. Committed revision 9351. I'm sorry for the delay, I forgot this bug completely. I removed hunk from e_gw_item_new_from_soap_parameter, because that has been there already from some other fix, and I also removed this hunk: Index: servers/groupwise/soup-soap-message.c =================================================================== --- servers/groupwise/soup-soap-message.c (revision 8667) +++ servers/groupwise/soup-soap-message.c (working copy) @@ -744,7 +744,9 @@ soup_soap_message_persist (SoupSoapMessa /* serialize to SoupMessage class */ soup_message_set_request (SOUP_MESSAGE (msg), "text/xml", - SOUP_MEMORY_TAKE, (char *)body, len); + SOUP_MEMORY_TAKE, (const char *)body, len); + + xmlFree (body); } /**
Do we keep this opened?
I guess we can close it, we will open separate bug if we find any major leak in 2.23.x.
OK, closing as the above approve.