Red Hat Bugzilla – Bug 135531
evolution-connector backend eats all available memory
Last modified: 2007-11-30 17:07:13 EST
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):
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
3. start evolution.
The process that uses the cpu and memory is called
(Renaming the bug report to reflect that the problem appears to be in
Looks like a possible duplicate of this upstream bug:
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?
44MB in size. When the evolution is not running.
How many calendar events do you have on the server? That file sounds
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.
Not that many. Seems like this was the case.
dmalcolm, ping - need to fix or punt to update
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...
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.
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.
Punting to RHEL4 U1 tracker bug since I can't reproduce it.
(and because we have a workaround)
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 .. :) )
Moving this back to assigned, as we're no longer waiting on information.
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.
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 ?)
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
Am investigating applying the fix for RHEL4...
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!
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.