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 329251 - evolution-exchange-storage leaks memory continuously
evolution-exchange-storage leaks memory continuously
Status: RESOLVED INVALID
Product: Evolution Exchange
Classification: Deprecated
Component: Connector
2.4.x
Other All
: Normal normal
: 2.5
Assigned To: Sushma Rai
Ximian Connector QA
Depends on:
Blocks: 327514
 
 
Reported: 2006-01-30 19:49 UTC by Ben Armstrong
Modified: 2008-05-02 09:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
valgrind output for evolution-exchange-storage showing leak (36.16 KB, text/plain)
2006-01-30 19:52 UTC, Ben Armstrong
  Details
patch to fix the leaks detected by valgrind. (5.69 KB, patch)
2006-01-31 06:51 UTC, Sushma Rai
none Details | Review
Valgrind confirms evolution-data-server no longer leaks (27.82 KB, text/plain)
2006-01-31 15:51 UTC, Ben Armstrong
  Details
Valgrind output for patched evolution-exchange-storage (backported from CVS) still shows leakage (35.11 KB, text/plain)
2006-01-31 15:53 UTC, Ben Armstrong
  Details
Valgrind output for corrected patch backported to evo 2.4.2.1 (36.08 KB, text/plain)
2006-01-31 17:34 UTC, Ben Armstrong
  Details
Patch with some more leak fixes. (19.37 KB, patch)
2006-02-01 06:54 UTC, Sushma Rai
none Details | Review
Error message after patching 2.4.2.1 (10.42 KB, image/png)
2006-02-01 12:42 UTC, Ben Armstrong
  Details
Valgrind output after latest patch (38.09 KB, text/plain)
2006-02-01 13:58 UTC, Ben Armstrong
  Details
patch - evolution plugin leaks (1.43 KB, patch)
2006-02-01 15:18 UTC, Sushma Rai
committed Details | Review
My 2.4.2.1 backport of the evolution-data-server portion of the patch (8.82 KB, patch)
2006-02-01 18:11 UTC, Ben Armstrong
none Details | Review
My 2.4.2.1 backport of the ximian-connector portion of the patch (5.81 KB, patch)
2006-02-01 18:13 UTC, Ben Armstrong
none Details | Review
patch (2.57 KB, patch)
2006-02-02 06:14 UTC, Sushma Rai
committed Details | Review
Backport for 2.4.2.1 of all evolution-data-server patches to date (9.22 KB, patch)
2006-02-02 19:00 UTC, Ben Armstrong
none Details | Review
Backport for 2.4.2.1 of all ximian-connector patches to date (6.47 KB, patch)
2006-02-02 19:04 UTC, Ben Armstrong
none Details | Review
patch with e2k_results_free only on success (20.33 KB, patch)
2006-02-03 14:08 UTC, Sushma Rai
none Details | Review
patch - corrected some more issues (23.42 KB, patch)
2006-02-04 09:17 UTC, Sushma Rai
committed Details | Review
patch - exchange and eds (3.32 KB, patch)
2006-02-07 14:39 UTC, Sushma Rai
committed Details | Review
patch - leak in plugin (580 bytes, patch)
2006-02-10 05:51 UTC, Sushma Rai
committed Details | Review
valgrind report for calendar and tasks operation (7.58 KB, text/plain)
2006-02-23 08:46 UTC, Sushma Rai
  Details
Patch for the leaks in comment #37 (8.69 KB, patch)
2006-02-23 08:48 UTC, Sushma Rai
needs-work Details | Review
reworked patch.. also fixes one more leak in remove_task_object() (9.65 KB, patch)
2006-02-25 06:23 UTC, Sushma Rai
committed Details | Review
Fixs leaks in evolution exchange plugin (1.21 KB, patch)
2006-02-25 06:25 UTC, Sushma Rai
committed Details | Review
freeing the gconf values (1.92 KB, patch)
2006-02-27 09:28 UTC, Sushma Rai
committed Details | Review
valgrind report (2.60 KB, text/plain)
2006-03-01 14:50 UTC, Sushma Rai
  Details
patch for the leaks above. (1.83 KB, patch)
2006-03-01 14:53 UTC, Sushma Rai
committed Details | Review
valgrind report (6.36 KB, text/plain)
2006-03-03 07:42 UTC, Sushma Rai
  Details
patch for the leaks, memory corruption, for the traces in the comment #45 (4.77 KB, patch)
2006-03-03 07:45 UTC, Sushma Rai
none Details | Review
new patch, corrected an invalid free in the last patch (3.70 KB, patch)
2006-03-04 06:50 UTC, Sushma Rai
committed Details | Review
valgrind report (2.78 KB, text/plain)
2006-03-04 09:13 UTC, Sushma Rai
  Details
Patch for the leaks in above report. (1.82 KB, patch)
2006-03-04 09:14 UTC, Sushma Rai
committed Details | Review
valgrind output corresponding to comment 54 (48.50 KB, text/plain)
2006-03-13 16:18 UTC, Bryan christ
  Details
dmesg output corresponding to comment 54 (2.23 KB, text/plain)
2006-03-13 16:21 UTC, Bryan christ
  Details

Description Ben Armstrong 2006-01-30 19:49:50 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:
Comment 1 Ben Armstrong 2006-01-30 19:52:16 UTC
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
Comment 2 Sushma Rai 2006-01-31 04:56:13 UTC
Thanks for providing the valgrind report.
Comment 3 Sushma Rai 2006-01-31 06:51:09 UTC
Created attachment 58445 [details] [review]
patch to fix the leaks detected by valgrind.
Comment 4 Ben Armstrong 2006-01-31 13:20:17 UTC
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,
Comment 5 Ben Armstrong 2006-01-31 15:49:50 UTC
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.
Comment 6 Ben Armstrong 2006-01-31 15:51:46 UTC
Created attachment 58474 [details]
Valgrind confirms evolution-data-server no longer leaks
Comment 7 Ben Armstrong 2006-01-31 15:53:00 UTC
Created attachment 58475 [details]
Valgrind output for patched evolution-exchange-storage (backported from CVS) still shows leakage
Comment 8 Ben Armstrong 2006-01-31 16:12:51 UTC
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
Comment 9 Ben Armstrong 2006-01-31 17:31:36 UTC
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?
Comment 10 Ben Armstrong 2006-01-31 17:34:05 UTC
Created attachment 58478 [details]
Valgrind output for corrected patch backported to evo 2.4.2.1
Comment 11 Sushma Rai 2006-02-01 06:54:31 UTC
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.
Comment 12 Ben Armstrong 2006-02-01 12:42:46 UTC
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?
Comment 13 Ben Armstrong 2006-02-01 12:49:42 UTC
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.

Comment 14 Ben Armstrong 2006-02-01 13:02:42 UTC
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
Comment 15 Ben Armstrong 2006-02-01 13:07:04 UTC
Sorry about the double paste; those errors only happened once.  My VNC session seems to have a mouse bounce & key bounce problem today.
Comment 16 Ben Armstrong 2006-02-01 13:58:08 UTC
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.
Comment 17 Sushma Rai 2006-02-01 15:18:28 UTC
Created attachment 58527 [details] [review]
patch - evolution plugin leaks

Not reported by valgrind. But I found some leaks in folder subscription code.
Comment 18 Ben Armstrong 2006-02-01 18:11:17 UTC
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.
Comment 19 Ben Armstrong 2006-02-01 18:13:24 UTC
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.
Comment 20 Ben Armstrong 2006-02-01 18:15:45 UTC
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
Comment 21 Sushma Rai 2006-02-02 04:59:17 UTC
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.
Comment 22 Sushma Rai 2006-02-02 05:03:56 UTC
patches in #18 and #19 look good to me.
Comment 23 Sushma Rai 2006-02-02 06:07:55 UTC
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;
Comment 24 Sushma Rai 2006-02-02 06:14:43 UTC
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).
Comment 25 Ben Armstrong 2006-02-02 12:48:20 UTC
(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.
Comment 26 Sushma Rai 2006-02-02 13:37:27 UTC
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.
Comment 27 Ben Armstrong 2006-02-02 13:54:01 UTC
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.

Thread NaN (LWP 22971)

  • #0 strlen
    from /lib/tls/libc.so.6
  • #1 camel_url_free
    from /usr/lib/libcamel-1.2.so.0
  • #2 exchange_config_listener_get_type
  • #3 exchange_config_listener_migrate_esources
  • #4 g_cclosure_marshal_VOID__OBJECT
    from /usr/lib/libgobject-2.0.so.0
  • #5 g_cclosure_new_swap
    from /usr/lib/libgobject-2.0.so.0
  • #6 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #7 g_signal_stop_emission
    from /usr/lib/libgobject-2.0.so.0
  • #8 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #9 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #10 e_account_list_get_type
    from /usr/lib/evolution/2.4/libeutil.so.0
  • #11 e_account_list_construct
    from /usr/lib/evolution/2.4/libeutil.so.0
  • #12 exchange_config_listener_migrate_esources
  • #13 g_child_watch_add
    from /usr/lib/libglib-2.0.so.0
  • #14 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #15 g_main_context_check
    from /usr/lib/libglib-2.0.so.0
  • #16 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #17 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #18 main

Comment 28 Ben Armstrong 2006-02-02 19:00:42 UTC
Created attachment 58600 [details] [review]
Backport for 2.4.2.1 of all evolution-data-server patches to date
Comment 29 Ben Armstrong 2006-02-02 19:04:59 UTC
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.
Comment 30 Sushma Rai 2006-02-03 14:08:00 UTC
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
  • #0 free
    from /lib/tls/libc.so.6
  • #1 e2k_result_clear
    at e2k-result.c line 177
  • #2 e2k_results_free
    at e2k-result.c line 418
  • #3 open_calendar
    at e-cal-backend-exchange.c line 385

Comment 31 Sushma Rai 2006-02-04 09:17:05 UTC
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().
Comment 32 Sushma Rai 2006-02-06 08:54:01 UTC
Committed the patch to CVS head.
Comment 33 Sushma Rai 2006-02-07 14:37:28 UTC
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==






Comment 34 Sushma Rai 2006-02-07 14:39:51 UTC
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).
Comment 35 Sushma Rai 2006-02-09 12:40:01 UTC
Committed patch in comment #34 to cvs head, after incorporating
the comment in http://mail.gnome.org/archives/evolution-patches/2006-February/msg00026.html.
Comment 36 Sushma Rai 2006-02-10 05:51:53 UTC
Created attachment 59051 [details] [review]
patch - leak in plugin

This fixes one more leak in the Evolution plugins, and committed to cvs head.
Comment 37 Sushma Rai 2006-02-23 08:46:18 UTC
Created attachment 59986 [details]
valgrind report for calendar and tasks operation
Comment 38 Sushma Rai 2006-02-23 08:48:19 UTC
Created attachment 59987 [details] [review]
Patch for the leaks in comment #37
Comment 39 Chenthill P 2006-02-23 14:40:55 UTC
        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 :)).
Comment 40 Sushma Rai 2006-02-25 06:23:27 UTC
Created attachment 60094 [details] [review]
reworked patch.. also fixes one more leak in remove_task_object()
Comment 41 Sushma Rai 2006-02-25 06:25:43 UTC
Created attachment 60095 [details] [review]
Fixs leaks in evolution exchange plugin
Comment 42 Sushma Rai 2006-02-27 09:28:27 UTC
Created attachment 60218 [details] [review]
freeing the gconf values
Comment 43 Sushma Rai 2006-03-01 14:50:45 UTC
Created attachment 60405 [details]
valgrind report
Comment 44 Sushma Rai 2006-03-01 14:53:03 UTC
Created attachment 60406 [details] [review]
patch for the leaks above.
Comment 45 Sushma Rai 2006-03-03 07:42:52 UTC
Created attachment 60530 [details]
valgrind report
Comment 46 Sushma Rai 2006-03-03 07:45:45 UTC
Created attachment 60532 [details] [review]
patch for the leaks, memory corruption, for the traces in the comment  #45
Comment 47 Sushma Rai 2006-03-04 06:50:45 UTC
Created attachment 60623 [details] [review]
new patch, corrected an invalid free in the last patch
Comment 48 Sushma Rai 2006-03-04 09:13:28 UTC
Created attachment 60625 [details]
valgrind report
Comment 49 Sushma Rai 2006-03-04 09:14:46 UTC
Created attachment 60626 [details] [review]
Patch for the leaks in above report.
Comment 50 Sushma Rai 2006-03-06 06:43:12 UTC
Found and fixed many leaks to cvs head.
So it should not leak memory as before. Lowering the priority.
Comment 51 Ben Armstrong 2006-03-06 18:55:47 UTC
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?
Comment 52 Sushma Rai 2006-03-08 06:10:40 UTC
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.
Comment 53 Bryan christ 2006-03-10 15:50:59 UTC
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.
Comment 54 Sushma Rai 2006-03-11 06:38:24 UTC
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
Comment 55 Sushma Rai 2006-03-13 12:57:26 UTC
Poornima, Can we test this with 2.6?
Comment 56 Bryan christ 2006-03-13 15:59:43 UTC
Sushma,

I will run valgrind today.  How long do you need me to run it for?
Comment 57 Bryan christ 2006-03-13 16:17:09 UTC
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.
Comment 58 Bryan christ 2006-03-13 16:18:54 UTC
Created attachment 61184 [details]
valgrind output corresponding to comment 54
Comment 59 Bryan christ 2006-03-13 16:21:19 UTC
Created attachment 61185 [details]
dmesg output corresponding to comment 54
Comment 60 Sushma Rai 2006-04-06 14:22:48 UTC
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? 
Comment 61 Bryan christ 2006-04-06 14:53:12 UTC
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).
Comment 62 Bryan christ 2006-04-06 15:18:15 UTC
Gnome is version 2.14
Comment 63 Bryan christ 2006-08-15 19:55:43 UTC
Upgraded to evolution/connector 2.6.3 on FC5 and the leaks still continue.
Comment 64 Sushma Rai 2006-08-16 05:34:55 UTC
Ben Armstrong ,

Can you please verify once?
Comment 65 Ben Armstrong 2006-08-16 14:25:40 UTC
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.
Comment 66 Bryan christ 2006-08-16 16:16:48 UTC
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.
Comment 67 Tobias Mueller 2008-03-20 14:44:05 UTC
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.
Comment 68 Bryan christ 2008-03-20 14:59:31 UTC
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.
Comment 69 Akhil Laddha 2008-05-02 09:17:58 UTC
Closing as per comment#68 ..thanks Bryan