GNOME Bugzilla – Bug 329251
evolution-exchange-storage leaks memory continuously
Last modified: 2008-05-02 09:17:58 UTC
Please describe the problem: The evolution-exchange-storage plugin leaks memory continuously until my system begins to thrash. Steps to reproduce: 1. Start evolution 2. Connect to an Exchange account 3. Leave Evolution running (checks for mail on the Exchange account every 1 minute) Actual results: - memory usage increases at about 20M / hr - gconfd memory usage increases at a similar rate Expected results: Memory usage should eventually level out. Does this happen every time? Yes. Other information:
Created attachment 58412 [details] valgrind output for evolution-exchange-storage showing leak Command used to start evolution-exchange-storage: valgrind --leak-check=full --log-file=evolution-exchange-storage /usr/lib/evolution/2.4/evolution-exchange-storage
Thanks for providing the valgrind report.
Created attachment 58445 [details] [review] patch to fix the leaks detected by valgrind.
There is apparently a typo here. This should say "g_object_unref (folder);" not "g_boject_unref (folder);". diff -u -p -r1.8 exchange-hierarchy-webdav.c --- evolution-data-server/servers/exchange/storage/exchange-hierarchy-webdav.c 17 Dec 2005 07:23:12 -0000 1.8 +++ evolution-data-server/servers/exchange/storage/exchange-hierarchy-webdav.c 31 Jan 2006 06:49:10 -0000 @@ -729,6 +729,7 @@ scan_subtree (ExchangeHierarchy *hier, E subtrees = g_slist_prepend (subtrees, folder); } exchange_hierarchy_new_folder (hier, folder); + g_boject_unref (folder); /* Check the folder size here */ name = e2k_properties_get_prop (result->props,
I backported this patch into 2.4.2.1, and evolution-exchange still leaks. I submitted the backport patches against the Debian evolution-data-server and evolution-exchange packages. See the Debian bugs and the patches (including the typo fix indicated above) here: http://bugs.debian.org/350745 and http://bugs.debian.org/263278 I have attached two new valgrind logs, one for evolution-data-server itself, which now seems to no longer be leaking, and the other for evolution-exchange, which appears to still leak.
Created attachment 58474 [details] Valgrind confirms evolution-data-server no longer leaks
Created attachment 58475 [details] Valgrind output for patched evolution-exchange-storage (backported from CVS) still shows leakage
Oops. When I compared the original patch with my backport, I think I have spotted a hunk I missed: diff -u -p -r1.32 mail-stub-exchange.c --- evolution-exchange/mail/mail-stub-exchange.c 17 Dec 2005 07:27:19 -0000 1.32 +++ evolution-exchange/mail/mail-stub-exchange.c 31 Jan 2006 06:48:04 -0000 @@ -607,6 +610,8 @@ get_folder_online (MailStubExchangeFolde if (prop) mfld->deleted_count = atoi (prop); + e2k_results_free (results, nresults); + rn = e2k_restriction_andv ( e2k_restriction_prop_bool (E2K_PR_DAV_IS_COLLECTION, E2K_RELOP_EQ, FALSE), I will fix my patch and retest. Ben
Even with that hunk added now, evolution-exchange-storage still seems to lose quite a bit to orbit. The valgrind output is quite similar to before. What next? Is it possible for me to use valgrind to see where the memory lost to orbit comes from?
Created attachment 58478 [details] Valgrind output for corrected patch backported to evo 2.4.2.1
Created attachment 58497 [details] [review] Patch with some more leak fixes. One more patch which has some more fixes. Since the earlier patch is not committed yet, this is the combination of old patch and some more new fixes. This patch has fixes in e-d-s, exchange-storage and evolution exchange plugin code. Thank you very much for your time and effort in finding the leaks.
Created attachment 58511 [details] Error message after patching 2.4.2.1 I applied the latest patches (only to evolution-data-server and evolution-exchange, though, as I don't use evolution-plugins). After patching, the first time I start evolution, I get the error message shown in the attachment. Pressing "OK" does not remove the dialog box. After performing a "Force Quit" evolution starts without an error the second time. I'm not sure if this is due to a bug in the original patch, in my patch, or just a latent bug that was always there but now only shows up after patching. I am reluctant to run the CVS version of evolution on my office mail, which is why I have been spending the extra time to backport each patch. How can I locate this alleged invalid UTF-8 the error message complains about and fix it? And why do you suppose the dialog box can't be exited properly?
Oops. I forgot to include a second screenshot, but the "Details" button indicates there is invalid UTF-8 in my configuration. I have not yet reproduced the error. It doesn't seem to happen every time, even after performing an evolution --force-shutdown and ensuring with 'ps' that no evolution processes remain. If-and-when I reproduce it, I can include a screenshot of that dialog too.
Starting evolution-exchange-storage from my terminal first, I see this assertion fails when I subsequently start evolution. I don't know if it's related to my earlier problem or not. In this session, I did not get a recurrence of the UTF-8 error dialog. (evolution-exchange-storage:15094): libsoup-CRITICAL **: set_current_request: assertion `priv->cur_req == NULL' failed After exiting evolution, I then started evolution-exchange-storage a second time, but this time evolution-data-server was already running from the previous session. The error dialog came up again, and this output appeared in my terminal session: error : xmlEncodeEntitiesReentrant : input not UTF-8 encoding error : output conversion failed due to conv error, bytes 0xB8 0x5C 0x22 0x2F I/O error : encoder error error : xmlEncodeEntitiesReentrant : input not UTF-8 encoding error : output conversion failed due to conv error, bytes 0xB8 0x5C 0x22 0x2F I/O error : encoder error (evolution-exchange-storage:15147): e-data-server-WARNING **: Could not update "/apps/evolution/tasks/sources": Text contains invalid UTF-8 error : xmlEncodeEntitiesReentrant : input not UTF-8 encoding error : output conversion failed due to conv error, bytes 0xB8 0x5C 0x22 0x2F I/O error : encoder error error : xmlEncodeEntitiesReentrant : input not UTF-8 encoding error : output conversion failed due to conv error, bytes 0xB8 0x5C 0x22 0x2F I/O error : encoder error (evolution-exchange-storage:15147): e-data-server-WARNING **: Could not update "/apps/evolution/tasks/sources": Text contains invalid UTF-8
Sorry about the double paste; those errors only happened once. My VNC session seems to have a mouse bounce & key bounce problem today.
Created attachment 58520 [details] Valgrind output after latest patch This latest valgrind output from evolution-exchange-storage shows the leaks are all addressed by my backport to 2.4.2.1 of the latest patch.
Created attachment 58527 [details] [review] patch - evolution plugin leaks Not reported by valgrind. But I found some leaks in folder subscription code.
Created attachment 58533 [details] [review] My 2.4.2.1 backport of the evolution-data-server portion of the patch This is constructed as a dpatch for the Debian package of evolution-data-server. However, it should apply cleanly to upstream source.
Created attachment 58534 [details] [review] My 2.4.2.1 backport of the ximian-connector portion of the patch This is a diff between the current Debian release of this package and my version, so it includes the debian changelog entry. The rest of it should apply cleanly to upstream source.
After carefully rechecking the new patches I just posted, I have concluded my patches are correct (insofar as I understand the code) and that the dialog box that I'm encountering is a different problem altogether. I'd like to hear your opinion on this, as I would like to file these patches against my current open Debian bugs so that the leaks in the Debian packages will be resolved. Thanks for all of your help. Ben
I have not tested my patchs yet. Are you still seeing the error "Text contains invalid UTF-8" error? We need to make sure that it is not due to the patch.
patches in #18 and #19 look good to me.
I found that the fix in exchange-config-listener.c was buggy. Index: evolution-exchange/storage/exchange-config-listener.c =================================================================== RCS file: /cvs/gnome/evolution-exchange/storage/exchange-config-listener.c,v retrieving revision 1.31 diff -u -p -r1.31 exchange-config-listener.c --- evolution-exchange/storage/exchange-config-listener.c 28 Sep 2005 13:46:01 -0000 1.31 +++ evolution-exchange/storage/exchange-config-listener.c 1 Feb 2006 06:44:07 -0000 @@ -304,6 +304,7 @@ migrate_account_esource (EAccount *accou user_name = camel_url->user; authtype = camel_url->authmech; url_string = camel_url_to_string (camel_url, CAMEL_URL_HIDE_PASSWORD | CAMEL_URL_HIDE_PARAMS); + camel_url_free (camel_url); if (!user_name) return;
Created attachment 58567 [details] [review] patch This patch fixes leaks found in valgrind report in Comment #16 apart form calendar leak, for fixing it I need some more time. This also should fix the error in comment #12 (See my above comment, camel_url was supposed to be freed at the end).
(In reply to comment #21) > I have not tested my patchs yet. > Are you still seeing the error "Text contains invalid UTF-8" error? > We need to make sure that it is not due to the patch. I have not yet seen a recurrence of that error. However, I do not use tasks, except that I did have two tasks with no activity in over two years which I have since deleted. It may be that if I were to use tasks actively, this error would recur. I'll play with tasks a bit and see if the error turns up again.
The patch in comment #24 is the correct patch for exchange-config-listener.c and should fix the problem. It is good if you take that patch before testing.
Patches applied to 2.4.2.1. evolution-exchange-storage now segfaults every time I try to start it: Program received signal SIGSEGV, Segmentation fault.
+ Trace 65853
Thread NaN (LWP 22971)
Created attachment 58600 [details] [review] Backport for 2.4.2.1 of all evolution-data-server patches to date
Created attachment 58601 [details] [review] Backport for 2.4.2.1 of all ximian-connector patches to date This patch fixes the problem I mentioned in comment #27. My mistake. The seg fault was because when I backported your latest fixes, I accidentally left in a camel_url_free, so it was trying to free the same url twice.
Created attachment 58648 [details] [review] patch with e2k_results_free only on success Ben Armstrong, I think it is lots of re-work for you. I found that E2kresuts will be set only on MULTISTATUS and in the faliure case, since nresults is not initialized, it might contain some junk value > 0 and e2k_results_free might crash. now initializing nresults to 0 and free the results only on SUCCESS. fixes this crash... 0x419c51b9 in free () from /lib/tls/libc.so.6 (gdb) ba
+ Trace 65886
Created attachment 58693 [details] [review] patch - corrected some more issues this is the full patch for exchange, e-d-s and evo, with some changes in calling e2k_results_free().
Committed the patch to CVS head.
Ran valgrind and found some more leaks.. ==18184== Thread 5: ==18184== Invalid read of size 1 ==18184== at 0x57C2CD7: g_str_hash (gstring.c:95) ==18184== by 0x579DDF8: g_hash_table_lookup (ghash.c:242) ==18184== by 0x40351D8: e_data_book_view_notify_update (e-data-book-view.c:250) ==18184== by 0x8067493: e_book_backend_exchange_start_book_view (e-book-backend-exchange.c:1942) ==18184== by 0x4031987: e_book_backend_start_book_view (e-book-backend.c:304) ==18184== by 0x4035745: impl_GNOME_Evolution_Addressbook_BookView_start (e-data-book-view.c:441) ==18184== by 0x40278AA: _ORBIT_skel_small_GNOME_Evolution_Addressbook_BookView_start (Evolution-DataServer-Addressbook-common.c:36) ==18184== by 0x56D6855: ORBit_POAObject_invoke (poa.c:1145) ==18184== by 0x56DAD83: ORBit_OAObject_invoke (orbit-adaptor.c:336) ==18184== by 0x56C81B9: ORBit_small_invoke_adaptor (orbit-small.c:835) ==18184== by 0x56D6B4B: ORBit_POAObject_handle_request (poa.c:1354) ==18184== by 0x56D715A: ORBit_POAObject_invoke_incoming_request (poa.c:1422) ==18184== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==18184== ==18184== Thread 1: ==18184== Invalid read of size 1 ==18184== at 0x401D53F: strcpy (mac_replace_strmem.c:269) ==18184== by 0x40CDF81: icalrecurrencetype_as_string (icalrecur.c:586) ==18184== by 0x40D83C7: icalvalue_recur_as_ical_string (icalvalue.c:718) ==18184== by 0x40D8E81: icalvalue_as_ical_string (icalvalue.c:1018) ==18184== by 0x40CC3B9: icalproperty_as_ical_string (icalproperty.c:495) ==18184== by 0x40C39A4: icalcomponent_as_ical_string (icalcomponent.c:322) ==18184== by 0x40C3A0F: icalcomponent_as_ical_string (icalcomponent.c:334) ==18184== by 0x8075825: timeout_save_cache (e-cal-backend-exchange.c:261) ==18184== by 0x57AAAE3: g_timeout_dispatch (gmain.c:3257) ==18184== by 0x57A8EC3: g_main_context_dispatch (gmain.c:1913) ==18184== by 0x57AC04B: g_main_context_iterate (gmain.c:2544) ==18184== by 0x57AC337: g_main_loop_run (gmain.c:2748) ==18184== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==18184== ==18184== ==18184 in 7 blocks are possibly lost in loss record 95 of 215 ==18184== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==18184== by 0x5525FF3: xmlStrndup (xmlstring.c:45) ==18184== by 0x557345E: xmlSAX2TextNode (SAX2.c:1812) ==18184== by 0x5573C6F: xmlSAX2StartElementNs (SAX2.c:1963) ==18184== by 0x54C6A24: xmlParseStartTag2 (parser.c:8114) ==18184== by 0x54D2AD3: xmlParseElement (parser.c:8445) ==18184== by 0x54D1447: xmlParseContent (parser.c:8369) ==18184== by 0x54D2B42: xmlParseElement (parser.c:8529) ==18184== by 0x54D3382: xmlParseDocument (parser.c:9137) ==18184== by 0x54D3450: xmlSAXParseDoc (parser.c:12610) ==18184== by 0x54D34B2: xmlParseDoc (parser.c:12635) ==18184== by 0x4874213: e_source_list_is_gconf_updated (e-source-list.c:614 in 6 blocks are definitely lost in loss record 114 of 215 ==18184== ==18184== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==18184== by 0x5865835: vasprintf (in /lib/tls/libc-2.3.5.so) ==18184== by 0x57CFEBA: g_vasprintf (gprintf.c:313) ==18184== by 0x57C048D: g_strdup_vprintf (gstrfuncs.c:188) ==18184== by 0x57C04B5: g_strdup_printf (gstrfuncs.c:201) ==18184== by 0x8077E68: save_attach_file (e-cal-backend-exchange.c:1498) ==18184== by 0x8078027: get_attachment (e-cal-backend-exchange.c:1544) ==18184== by 0x806D1B0: add_ical (e-cal-backend-exchange-calendar.c:189) ==18184== by 0x806DB27: get_changed_events (e-cal-backend-exchange-calendar.c:424) ==18184== by 0x806DDF7: open_calendar (e-cal-backend-exchange-calendar.c:487) ==18184== by 0x40559CA: e_cal_backend_sync_open (e-cal-backend-sync.c:186) ==18184== by 0x4057497: _e_cal_backend_open (e-cal-backend-sync.c:662) ==18184== ==18184====18184== 720 bytes in 9 blocks are definitely lost in loss record 128 of 215 ==18184== at 0x401C806: realloc (vg_replace_malloc.c:306) ==18184== by 0x57AF928: g_realloc (gmem.c:155) ==18184== by 0x57C2DD9: g_string_maybe_expand (gstring.c:261) ==18184== by 0x57C3084: g_string_insert_len (gstring.c:490) ==18184== by 0x57C323B: g_string_append_len (gstring.c:530) ==18184== by 0x579D196: g_build_path_va (gfileutils.c:1549) ==18184== by 0x579D3BB: g_build_filename (gfileutils.c:1819) ==18184== by 0x4768350: e_folder_exchange_get_storage_file (e-folder-exchange.c:414) ==18184== by 0x80752F0: load_cache (e-cal-backend-exchange.c:149) ==18184== by 0x8075E28: open_calendar (e-cal-backend-exchange.c:405) ==18184== by 0x806DD95: open_calendar (e-cal-backend-exchange-calendar.c:477) ==18184== by 0x40559CA: e_cal_backend_sync_open (e-cal-backend-sync.c:186) ==18184== ==18184 in 7 blocks are definitely lost in loss record 131 of 215 ==18184== at 0x401C806: realloc (vg_replace_malloc.c:306) ==18184== by 0x5865897: vasprintf (in /lib/tls/libc-2.3.5.so) ==18184== by 0x57CFEBA: g_vasprintf (gprintf.c:313) ==18184== by 0x57C048D: g_strdup_vprintf (gstrfuncs.c:188) ==18184== by 0x57C04B5: g_strdup_printf (gstrfuncs.c:201) ==18184== by 0x80753A7: load_cache (e-cal-backend-exchange.c:165) ==18184== by 0x8075E28: open_calendar (e-cal-backend-exchange.c:405) ==18184== by 0x806DD95: open_calendar (e-cal-backend-exchange-calendar.c:477) ==18184== by 0x40559CA: e_cal_backend_sync_open (e-cal-backend-sync.c:186) ==18184== by 0x4057497: _e_cal_backend_open (e-cal-backend-sync.c:662) ==18184== by 0x404EF25: e_cal_backend_open (e-cal-backend.c:616) ==18184== by 0x4058270: impl_Cal_open (e-data-cal.c:81) ==18184== ==18184====18184== ==18184== 1,024 bytes in 1 blocks are possibly lost in loss record 138 of 215 ==18184== at 0x401C806: realloc (vg_replace_malloc.c:306) ==18184== by 0x57AF928: g_realloc (gmem.c:155) ==18184== by 0x579210B: g_array_maybe_expand (garray.c:344) ==18184== by 0x5792303: g_array_append_vals (garray.c:132) ==18184== by 0x478B047: e2k_results_array_add_from_multistatus (e2k-result.c:326) ==18184== by 0x478B0F2: e2k_results_from_multistatus (e2k-result.c:368) ==18184== by 0x4780822: search_fetch (e2k-context.c:1879) ==18184== by 0x478B30C: iter_fetch (e2k-result.c:451) ==18184== by 0x478B3A2: e2k_result_iter_new (e2k-result.c:506) ==18184== by 0x4780AB1: e2k_context_search_start (e2k-context.c:1944) ==18184== by 0x4768BB5: e_folder_exchange_search_start (e-folder-exchange.c:657) ==18184== by 0x80645C4: update_cache (e-book-backend-exchange.c:516) ==18184== ==18184== ==18184== ==18184== 1,665 (1,536 direct, 129 indirect) bytes in 3 blocks are definitely lost in loss record 151 of 215 ==18184== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==18184== by 0x5523C8D: xmlGetGlobalState (threads.c:455) ==18184== by 0x5523068: __xmlDefaultSAXHandler (globals.c:821) ==18184== by 0x55748A5: xmlDefaultSAXHandlerInit (SAX2.c:2754) ==18184== by 0x54BCD94: xmlInitParserCtxt (parserInternals.c:1521) ==18184== by 0x54BD5BF: xmlNewParserCtxt (parserInternals.c:1775) ==18184== by 0x54CE8F2: xmlCreateMemoryParserCtxt (parser.c:12379) ==18184== by 0x47922B9: e2k_parse_xml (e2k-xml-utils.c:68) ==18184== by 0x478AD68: e2k_results_array_add_from_multistatus (e2k-result.c:287) ==18184== by 0x478B0F2: e2k_results_from_multistatus (e2k-result.c:368) ==18184== by 0x4780822: search_fetch (e2k-context.c:1879) ==18184== by 0x478B30C: iter_fetch (e2k-result.c:451) ==18184== ==18184====18184== ==18184== 496,646 (15,488 direct, 481,158 indirect) bytes in 176 blocks are definitely lost in loss record 174 of 215 ==18184== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==18184== by 0x54D610C: xmlNewDoc (tree.c:1089) ==18184== by 0x5571E8B: xmlSAX2StartDocument (SAX2.c:960) ==18184== by 0x54D33BA: xmlParseDocument (parser.c:9091) ==18184== by 0x54D3450: xmlSAXParseDoc (parser.c:12610) ==18184== by 0x54D34B2: xmlParseDoc (parser.c:12635) ==18184== by 0x4874213: e_source_list_is_gconf_updated (e-source-list.c:614) ==18184== by 0x48740DB: e_source_list_sync (e-source-list.c:577) ==18184== by 0x4772429: add_folder_esource (exchange-esource.c:154) ==18184== by 0x47679D9: e_folder_exchange_new (e-folder-exchange.c:185) ==18184== by 0x4776031: e_folder_webdav_new (exchange-hierarchy-webdav.c:265) ==18184== by 0x4776DDF: exchange_hierarchy_webdav_parse_folder (exchange-hierarchy-webdav.c:646) ==18184== ==18184== ==18184== ==18184== 796,344 (795,248 direct, 1,096 indirect) bytes in 1,367 blocks are definitely lost in loss record 215 of 215 ==18184== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==18184== by 0x57AF861: g_malloc (gmem.c:122) ==18184== by 0x48729E1: e_source_group_to_xml (e-source-group.c:663) ==18184== by 0x487424F: e_source_list_is_gconf_updated (e-source-list.c:620) ==18184== by 0x48740DB: e_source_list_sync (e-source-list.c:577) ==18184== by 0x4772429: add_folder_esource (exchange-esource.c:154) ==18184== by 0x47679D9: e_folder_exchange_new (e-folder-exchange.c:185) ==18184== by 0x4776031: e_folder_webdav_new (exchange-hierarchy-webdav.c:265) ==18184== by 0x4776DDF: exchange_hierarchy_webdav_parse_folder (exchange-hierarchy-webdav.c:646) ==18184== by 0x4777027: scan_subtree (exchange-hierarchy-webdav.c:722) ==18184== by 0x4778342: exchange_hierarchy_scan_subtree (exchange-hierarchy.c:319) ==18184== by 0x476DDF8: exchange_account_rescan_tree (exchange-account.c:340) ==18184====25583== Thread 5: ==25583== Invalid read of size 1 ==25583== at 0x47925ED: e2k_g_string_append_xml_escaped (e2k-xml-utils.c:163) ==25583== by 0x477F4A2: write_prop (e2k-context.c:1318) ==25583== by 0x477F513: add_set_props (e2k-context.c:1335) ==25583== by 0x4788477: foreach_callback (e2k-properties.c:492) ==25583== by 0x579D85E: g_hash_table_foreach (ghash.c:614) ==25583== by 0x47884DC: e2k_properties_foreach (e2k-properties.c:517) ==25583== by 0x477F660: patch_msg (e2k-context.c:1380) ==25583== by 0x477F8CC: e2k_context_proppatch (e2k-context.c:1442) ==25583== by 0x806637E: e_book_backend_exchange_modify_contact (e-book-backend-exchange.c:1411) ==25583== by 0x402F900: e_book_backend_sync_modify_contact (e-book-backend-sync.c:147) ==25583== by 0x4030669: _e_book_backend_modify_contact (e-book-backend-sync.c:409) ==25583== by 0x4031565: e_book_backend_modify_contact (e-book-backend.c:234) ==25583== Address 0x6F26CD8 is 0 bytes inside a block of size 6 free'd ==25583== at 0x401BF57: free (vg_replace_malloc.c:235) ==25583== by 0x57AF9A1: g_free (gmem.c:172) ==25583== by 0x8065328: proppatch_address (e-book-backend-exchange.c:980) ==25583== by 0x8065832: props_from_contact (e-book-backend-exchange.c:1110) ==25583== by 0x806635D: e_book_backend_exchange_modify_contact (e-book-backend-exchange.c:1410) ==25583== by 0x402F900: e_book_backend_sync_modify_contact (e-book-backend-sync.c:147) ==25583== by 0x4030669: _e_book_backend_modify_contact (e-book-backend-sync.c:409) ==25583== by 0x4031565: e_book_backend_modify_contact (e-book-backend.c:234) ==25583== by 0x40363D4: impl_GNOME_Evolution_Addressbook_Book_modifyContact (e-data-book.c:133) ==25583== by 0x4027A17: _ORBIT_skel_small_GNOME_Evolution_Addressbook_Book_modifyContact (Evolution-DataServer-Addressbook-common.c:72) ==25583== by 0x56D6855: ORBit_POAObject_invoke (poa.c:1145) ==25583== by 0x56DAD83: ORBit_OAObject_invoke (orbit-adaptor.c:336) ==25583== ==25583== ==25583== 641 (112 direct, 529 indirect) bytes in 7 blocks are definitely lost in loss record 83 of 186 ==25583== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==25583== by 0x401C785: realloc (vg_replace_malloc.c:306) ==25583== by 0x57AF928: g_realloc (gmem.c:155) ==25583== by 0x579210B: g_array_maybe_expand (garray.c:344) ==25583== by 0x5792303: g_array_append_vals (garray.c:132) ==25583== by 0x478B047: e2k_results_array_add_from_multistatus (e2k-result.c:326) ==25583== by 0x478B0F2: e2k_results_from_multistatus (e2k-result.c:368) ==25583== by 0x4780100: e2k_context_propfind (e2k-context.c:1664) ==25583== by 0x80662DB: e_book_backend_exchange_modify_contact (e-book-backend-exchange.c:1395) ==25583== by 0x402F900: e_book_backend_sync_modify_contact (e-book-backend-sync.c:147) ==25583== by 0x4030669: _e_book_backend_modify_contact (e-book-backend-sync.c:409) ==25583== by 0x4031565: e_book_backend_modify_contact (e-book-backend.c:234) ==25583== ==1659== 247,727 (8,096 direct, 239,631 indirect) bytes in 92 blocks are definitely lost in loss record 165 of 183 ==1659== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==1659== by 0x54D610C: xmlNewDoc (tree.c:1089) ==1659== by 0x5571E8B: xmlSAX2StartDocument (SAX2.c:960) ==1659== by 0x54D33BA: xmlParseDocument (parser.c:9091) ==1659== by 0x54D3450: xmlSAXParseDoc (parser.c:12610) ==1659== by 0x54D34B2: xmlParseDoc (parser.c:12635) ==1659== by 0x4874213: e_source_list_is_gconf_updated (e-source-list.c:614) ==1659== by 0x48740DB: e_source_list_sync (e-source-list.c:577) ==1659== by 0x8057E4A: migrate_account_esource (exchange-config-listener.c:351) ==1659== by 0x8057F31: exchange_config_listener_migrate_esources (exchange-config-listener.c:369) ==1659== by 0x8058078: account_added (exchange-config-listener.c:408) ==1659== by 0x5719BDC: g_cclosure_marshal_VOID__OBJECT (gmarshal.c:636) ==1659== ==1659== ==3682== Thread 3: ==3682== Invalid read of size 4 ==3682== at 0x8068DC2: ldap_op_finished (e-book-backend-gal.c:325) ==3682== by 0x806BABB: stop_book_view (e-book-backend-gal.c:1553) ==3682== by 0x4031ACB: e_book_backend_stop_book_view (e-book-backend.c:324) ==3682== by 0x40357A2: impl_GNOME_Evolution_Addressbook_BookView_stop (e-data-book-view.c:450) ==3682== by 0x40278C3: _ORBIT_skel_small_GNOME_Evolution_Addressbook_BookView_stop (Evolution-DataServer-Addressbook-common.c:40) ==3682== by 0x56D6855: ORBit_POAObject_invoke (poa.c:1145) ==3682== by 0x56DAD83: ORBit_OAObject_invoke (orbit-adaptor.c:336) ==3682== by 0x56C81B9: ORBit_small_invoke_adaptor (orbit-small.c:835) ==3682== by 0x56D6B4B: ORBit_POAObject_handle_request (poa.c:1354) ==3682== by 0x56D715A: ORBit_POAObject_invoke_incoming_request (poa.c:1422) ==3682== by 0x56C2747: giop_thread_queue_process (giop.c:774) ==3682== by 0x56C27F8: giop_request_handler_thread (giop.c:484) ==3682== Address 0x5F72F18 is 8 bytes inside a block of size 40 free'd ==3682== at 0x401BF57: free (vg_replace_malloc.c:235) ==3682== by 0x57AF9A1: g_free (gmem.c:172) ==3682== by 0x806B647: ldap_search_dtor (e-book-backend-gal.c:1430) ==3682== by 0x8068E95: ldap_op_finished (e-book-backend-gal.c:337) ==3682== by 0x806B5A1: ldap_search_handler (e-book-backend-gal.c:1408) ==3682== by 0x806B1D5: poll_ldap (e-book-backend-gal.c:1325) ==3682== by 0x57AAAE3: g_timeout_dispatch (gmain.c:3257) ==3682== by 0x57A8EC3: g_main_context_dispatch (gmain.c:1913) ==3682== by 0x57AC04B: g_main_context_iterate (gmain.c:2544) ==3682== by 0x57AC337: g_main_loop_run (gmain.c:2748) ==3682== by 0x561743D: bonobo_main (bonobo-main.c:312) ==3682== by 0x805A941: main (main.c:238) ==3682====3682== ==3682== Invalid read of size 4 ==3682== at 0x57CF3B7: g_int_hash (gutils.c:2838) ==3682== by 0x8068E0D: ldap_op_finished (e-book-backend-gal.c:329) ==3682== by 0x806BABB: stop_book_view (e-book-backend-gal.c:1553) ==3682== by 0x4031ACB: e_book_backend_stop_book_view (e-book-backend.c:324) ==3682== by 0x40357A2: impl_GNOME_Evolution_Addressbook_BookView_stop (e-data-book-view.c:450) ==3682== by 0x40278C3: _ORBIT_skel_small_GNOME_Evolution_Addressbook_BookView_stop (Evolution-DataServer-Addressbook-common.c:40) ==3682== by 0x56D6855: ORBit_POAObject_invoke (poa.c:1145) ==3682== by 0x56DAD83: ORBit_OAObject_invoke (orbit-adaptor.c:336) ==3682== by 0x56C81B9: ORBit_small_invoke_adaptor (orbit-small.c:835) ==3682== by 0x56D6B4B: ORBit_POAObject_handle_request (poa.c:1354) ==3682== by 0x56D715A: ORBit_POAObject_invoke_incoming_request (poa.c:1422) ==3682== by 0x56C2747: giop_thread_queue_process (giop.c:774) ==3682== Address 0x5F72F28 is 24 bytes inside a block of size 40 free'd ==3682== at 0x401BF57: free (vg_replace_malloc.c:235) ==3682== by 0x57AF9A1: g_free (gmem.c:172) ==3682== by 0x806B647: ldap_search_dtor (e-book-backend-gal.c:1430) ==3682== by 0x8068E95: ldap_op_finished (e-book-backend-gal.c:337) ==3682== by 0x806B5A1: ldap_search_handler (e-book-backend-gal.c:1408) ==3682== by 0x806B1D5: poll_ldap (e-book-backend-gal.c:1325) ==3682== by 0x57AAAE3: g_timeout_dispatch (gmain.c:3257) ==3682== by 0x57A8EC3: g_main_context_dispatch (gmain.c:1913) ==3682== by 0x57AC04B: g_main_context_iterate (gmain.c:2544) ==3682== by 0x57AC337: g_main_loop_run (gmain.c:2748) ==3682== by 0x561743D: bonobo_main (bonobo-main.c:312) ==3682== by 0x805A941: main (main.c:238) ==3682====8248== 32 bytes in 1 blocks are possibly lost in loss record 46 of 189 ==8248== at 0x401B43A: malloc (vg_replace_malloc.c:149) ==8248== by 0x40CB9D4: icalproperty_new_impl (icalproperty.c:102) ==8248== by 0x40CBAAC: icalproperty_new_clone (icalproperty.c:134) ==8248== by 0x40C35B0: icalcomponent_new_clone (icalcomponent.c:199) ==8248== by 0x806D459: add_ical (e-cal-backend-exchange-calendar.c:240) ==8248== by 0x806DB2F: get_changed_events (e-cal-backend-exchange-calendar.c:424) ==8248== by 0x806DDFF: open_calendar (e-cal-backend-exchange-calendar.c:487) ==8248== by 0x40559CA: e_cal_backend_sync_open (e-cal-backend-sync.c:186) ==8248== by 0x4057497: _e_cal_backend_open (e-cal-backend-sync.c:662) ==8248== by 0x404EF25: e_cal_backend_open (e-cal-backend.c:616) ==8248== by 0x4058270: impl_Cal_open (e-data-cal.c:81) ==8248== by 0x4049538: _ORBIT_skel_small_GNOME_Evolution_Calendar_Cal_open (Evolution-DataServer-Calendar-common.c:44) ==8248==
Created attachment 58861 [details] [review] patch - exchange and eds Fixes exchange calendar and e-source related leaks. Also fixes a memory corruption in address book (mailing addresses).
Committed patch in comment #34 to cvs head, after incorporating the comment in http://mail.gnome.org/archives/evolution-patches/2006-February/msg00026.html.
Created attachment 59051 [details] [review] patch - leak in plugin This fixes one more leak in the Evolution plugins, and committed to cvs head.
Created attachment 59986 [details] valgrind report for calendar and tasks operation
Created attachment 59987 [details] [review] Patch for the leaks in comment #37
e_cal_component_set_icalcomponent (cache_comp, ecalbexcomp->icomp); *old_object = e_cal_component_get_as_string (cache_comp); - g_free (cache_comp); + //g_free (cache_comp); cache_comp needs be unref'ed. Please clone the ecalbexcomp->icomp while setting it to the cache_comp. char *name, *addr, *from_string; It would be safe to intialize the strings to NULL. Other than this the patch looks good. Please attach the ChangeLog. Please make these changes and commit after testing (i have also tested it, more testing always the better :)).
Created attachment 60094 [details] [review] reworked patch.. also fixes one more leak in remove_task_object()
Created attachment 60095 [details] [review] Fixs leaks in evolution exchange plugin
Created attachment 60218 [details] [review] freeing the gconf values
Created attachment 60405 [details] valgrind report
Created attachment 60406 [details] [review] patch for the leaks above.
Created attachment 60530 [details] valgrind report
Created attachment 60532 [details] [review] patch for the leaks, memory corruption, for the traces in the comment #45
Created attachment 60623 [details] [review] new patch, corrected an invalid free in the last patch
Created attachment 60625 [details] valgrind report
Created attachment 60626 [details] [review] Patch for the leaks in above report.
Found and fixed many leaks to cvs head. So it should not leak memory as before. Lowering the priority.
I've been waiting for this to settle down before re-attempting a backport. Is it safe to proceed now, then, basing my patch on all committed patches above?
I think you can proceed on this .. and along with these patches you also have to take the changes, 2006-02-25 Sushma Rai <rsushma@novell.com> * storage/exchange-hierarchy-webdav.c (scan_subtree): Do not unref the folder which is being used later in subtrees. 2006-02-13 Chenthill Palanisamy <pchenthill@novell.com> * storage/exchange-hierarchy-webdav.c: (init), (hierarchy_new_folder): Ref the folder before inserting so that it doesn't die on before removing. Fixes #326413. CVS head revisions 1.10 and 1.11.
I am also seeing a similar memory leak. evolution-exchange-storage grow by about 10-20 MIB per hour. Eventually OOM killer spanks the process and I lose backend connectivity. The Evolution/Connector version I am using is 2.5.92 from Fedora Core 5 test 3.
Bryan, Is it possible for you to get the valgrind traces for evolution-exchange-storage? You need to use the command valgrind --leak-check=full --log-file=<some file> <your install prefix>/evolution-exchange-storage
Poornima, Can we test this with 2.6?
Sushma, I will run valgrind today. How long do you need me to run it for?
Shushma, No need to answer that last question. OOM already killed evolution-exchange-storage. I'm attaching the valgrind out put and the relevant section from dmesg.
Created attachment 61184 [details] valgrind output corresponding to comment 54
Created attachment 61185 [details] dmesg output corresponding to comment 54
Bryan christ, I am not able to get the traces/memory leak you are seeing. Does Evolution run for you without Exchange account? (Only IMAP/POP)? From the traces, I don't see anything useful other than one exchange-storage call gnome_program_init(). What is your gnome version?
Evolution does run without Exchange, but it is far less useful for me in my environment. Through connector I have access to my calendar and corp address book. In the past, I have used IMAP when connector was unavailabe (as you will know from our discussion in bug 273627 I have only been able to use connector again as of very recently).
Gnome is version 2.14
Upgraded to evolution/connector 2.6.3 on FC5 and the leaks still continue.
Ben Armstrong , Can you please verify once?
I'm sorry, I can't, as I no longer use Evolution. I found it too difficult to be the sole user in an entire network of Windows users, having to perform all of my own support on my own, and encountering repeated breakages that took far too much time for me to fix.* Ever since our net admins finally agreed to turn on IMAP, I have been free to choose whichever mail client meets my needs in areas other than just the ability to talk to Exchange server. For me, the ability to faithfully render HTML messages sent from Outlook clients scores high on that list of needs, and from my perspective, Thunderbird appears to be the better choice today. I did try just now to re-install evolution + the exchange plugin and recreate my account to test this for you, but I was immediately unable to connect to the server due to the backend dying (a problem that I was never able to resolve before) so I don't have the means to quickly verify the fix for you. Thanks for all of the help with this bug. I'm sorry I can't help further, and hope you manage to work it out without me. Good luck! Ben * I must say, though, that the experience here receiving help to fix this particular bug was overall a positive one, and was not a primary factor in deciding to make the switch. But there comes a time with any product when you have to decide whether the effort you're putting into it is worth it for the value you're getting out of it.
Ben, Regarding the backend crash, you should take a look at bugzilla 346120. This was fixed for me in the recent evo/conn version 2.6.3 just posted on my Fedora Core 5 yum repository.
Looks like this is not as issue anymore. Setting to NEEDINFO, if this is still an issue, feel free to reopen, it will be closed otherwise.
Since our company made the switch to Exchange 2007 I haven't been able to test this this issue as it was originally written. However, I have been using Evolution with IMAP and there are no significant memory leaks that I can see. I agree close now. Reopen later if needed.
Closing as per comment#68 ..thanks Bryan