Bug 135531 - evolution-connector backend eats all available memory
Summary: evolution-connector backend eats all available memory
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution-connector (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: i386 Linux
Target Milestone: ---
: ---
Assignee: Dave Malcolm
QA Contact:
Depends On:
Blocks: 137160
TreeView+ depends on / blocked
Reported: 2004-10-13 10:51 UTC by Samuli Järvinen
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version: RHBA-2005-236
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-09 12:31:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:236 normal SHIPPED_LIVE evolution-connector bug fix update 2005-06-09 04:00:00 UTC

Description Samuli Järvinen 2004-10-13 10:51:27 UTC
Description of problem:
When connecting to exchange server with evolution, evolution uses
about 70% of the memory, then stops to process something and uses the

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

How reproducible:
On my computer just start evolution and off you go.

Steps to Reproduce:
1.shutdown previous evolution (that is also eating the memory..)
2.issue evolution --force-shutdown ( or don't doesn't change the
behavior )
3. start evolution.
Actual results:

Expected results:

Additional info:
The process that uses the cpu and memory is called

Comment 1 Dave Malcolm 2004-10-13 22:14:41 UTC
(Renaming the bug report to reflect that the problem appears to be in

Comment 2 Dave Malcolm 2004-10-14 16:13:11 UTC
Looks like a possible duplicate of this upstream bug:

Comment 3 Dave Malcolm 2004-10-14 16:16:22 UTC
Also could be a duplicate of this upstream bug: 

Following up the suggestions in those bug reports, is there a large,
"cache.ics" file, located here?

Comment 4 Samuli Järvinen 2004-10-15 09:48:45 UTC
44MB in size. When the evolution is not running.

Comment 5 Dave Malcolm 2004-10-15 15:50:05 UTC
How many calendar events do you have on the server?  That file sounds
excessively large.  

In the upstream bug (XB 68246) there's a suggestion that the cache is
being appended, rather than cleared each time.  If you open the file
in a text editor/viewer when evolution isn't running you may be able
to confirm this hypothesis; alternatively, if the data in the calendar
isn't confidential/sensitive you could attach it to this bug report
and I can have a look at it.

Comment 6 Samuli Järvinen 2004-11-09 16:59:16 UTC
Not that many. Seems like this was the case.

Comment 7 Havoc Pennington 2004-11-10 16:48:56 UTC
dmalcolm, ping - need to fix or punt to update

Comment 8 Havoc Pennington 2004-11-16 00:55:19 UTC
additional ping

Comment 9 Dave Malcolm 2004-11-17 02:27:45 UTC
Comments at http://bugzilla.ximian.com/show_bug.cgi?id=64403 suggest
that this is a problem associated with an update occurring to a
recurring meeting.  I'm trying to reproduce this bug on my own machine...

Comment 10 Dave Malcolm 2004-11-17 02:52:36 UTC
Also, note that a workaround appears to be to delete the cache.ics
file  mentioned in comment #3 above.  However, if anyone can reproduce
the bug, I'd appreciate receiving a copy of that file before you
delete it (gzipped up, probably), for further analysis.

I haven't yet been able to reproduce the bug, but I'll keep trying.

Comment 11 Dave Malcolm 2004-11-29 23:46:29 UTC
I've been trying but have been unable to reproduce this bug; I will

We have a workaround, which is to delete:

Though if anyone does experience this bug, I'd be grateful if you
could email me the contents of that file before deleting it.

Comment 12 Dave Malcolm 2004-11-29 23:48:19 UTC
Punting to RHEL4 U1 tracker bug since I can't reproduce it.

Comment 13 Dave Malcolm 2004-11-29 23:49:22 UTC
(and because we have a workaround)

Comment 14 Lars Jonsson 2004-12-20 12:37:19 UTC
I recently had the same problem with FC3 and evo 2.0.2.
suddendly when I was accepting a meeting the
evolution-exchange-storage proccess starting to eat up all resources
(memory/cpu). When killing it and restarted evolution it starts again
when accessing the calender.. At first a thought it was some kind of
big attachement in the meeting so I used Outlook to remove the meeting
but that wasnt the case.. then I found this bug here on bugzilla.. so
I was able to remove the cache.ics (77MB) file.. But I have saved it,
 so please send me an email and I will send it to you.. (I dont what
the whole world to see my meetings and email adresses .. :) )

Comment 15 Jay Turner 2005-01-14 14:35:56 UTC
Moving this back to assigned, as we're no longer waiting on information.

Comment 16 Dave Jenkins 2005-01-20 09:09:40 UTC
I have this same issue, running FC3 attempting to connect to an
exchange server.  Everything runs fine until I try to connect the
Calendar.  My cache.ics file is currently 25MB, and whenever I access
the Calendar, evolution-exchange-storage begins to eat my memory
(consuming almost all of the 512MB I have on this machine in about 10

I am happy to send whatever files, run debugs, or cooperate in anyway.

Comment 17 Nick 2005-02-10 15:29:22 UTC
Hi I have the same problem on FC3 with evo 2.0.2.


is very small.... but a cache.ics  in
is 49Mb ... what is the impact of deleting it ? (will My machine just
hang until it's big again ?)

Comment 18 Dave Malcolm 2005-02-25 22:39:15 UTC
Also reported upstream here:

with a fix, that made it into 2.0.4

evolution-connector-2.0.4 is available as a test update for FC3

Comment 19 Dave Malcolm 2005-02-25 22:40:04 UTC
Am investigating applying the fix for RHEL4...

Comment 21 Christopher D. Maestas 2005-03-15 17:37:02 UTC
Don't know the impact of deleting my file neither.  This happens on my RHEL4
dist on my laptop w/ 1 GB of memory .... oh I love swapping!

Comment 22 Tim Powers 2005-06-09 12:31:29 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.