GNOME Bugzilla – Bug 264403
evolution-exchange-storange hangs evolution and has huge memory leak
Last modified: 2005-03-08 17:54:54 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: I get a meeting request, and I click on the message. Evolution freezes, and my whole system slows down. When I look at top, sorted by memory, evolution-exchange-storage is in a loop consuming more and more memory. This hasn't happened on every meeting request... but on this one message, it happens every time. I had to accept it by going to Outlook. (On Codeweavers Crossover of course. :) Steps to reproduce the problem: 1. Get a meeting request. 2. Click on the message. 3. Watch exchange-storage spin out of control. Additional Information: Evolution/connector 1.5.93, built from GARNOME 2.6.2.1 tarball, talking to Exchange via SSL (gnutls-1.0.13, libgcrypt-1.2.0, evo-ldap-2.0.27-1.ximian.8.1).
I am lowering the priority of this bug as this happens only with one particular appointment. Is it possible for you to send that appointment to my email-id <asarfraaz@novell.com> ? I would need that to reproduce this bug. Also, on your machine, when you get a hang, please attach gdb to the evolution-exchange process [ using gdb -p <evolution-exchange pid> ] and do a "thread apply all bt". Please attach the output of that to this bug report.
Ok, after playing around some more with evolution/exchange, I have seen this happen on other occasions that have nothing to do with accepting a meeting. In fact, connector is unusuble to me when it comes to the Calendar component because it triggers this bug (memory hog look that freezes my machine until I can kill the process). Right now I can reproduce it by just clicking on the Calendar and selecting the exchange account calendar. What can I do to help you debug this?
Right now I can reproduce it 100% of the time. I have my exchange calendar be the default view when I start evolution, and if I do: # killall evolution-data-server-1.0 evolution-alarm-notify evolution-1.5 evolution-exchange-storage # evolution-1.5 & It will happen just by starting up evolution, before I even do anything.
Oops, forgot you already told me what I could do to help. I thought it might be useful to see the output, three times a few seconds apart, Here is the gdb output for the first thread dump, about 5-10 seconds after starting evolution, with top showing evolution-exchange-storage already climbing in memory to 600m virtual/540m resident/21m shared memory: (gdb) thread apply all bt
+ Trace 49940
Thread 4 (Thread 126716848 (LWP 4182))
Thread 3 (Thread 31624112 (LWP 4185))
Thread 2 (Thread 42113968 (LWP 4199))
5 seconds later:
+ Trace 49941
Thread 1 (Thread -151166848 (LWP 4180))
Another 5 seconds later:
+ Trace 49942
5 more seconds. At this point my machine starts to freeze up, and top shows the process at 1057m virt/817m resident/21m shared.
+ Trace 49943
Ok, so it's clearly stuck loading something from some cache. Poking around I found this: (993) ~/.evolution/exchange/racevedo@sfmbx01.ad.hotwirebiz.com: ls -l personal/subfolders/Calendar/ total 44260 -rw-rw-r-- 1 raul raul 45268443 Sep 7 00:59 cache.ics -rw-rw-r-- 1 raul raul 494 Sep 7 00:43 connector-metadata.xml That doesn't look good. :) I removed the file, restarted all evolution processes, and it's fine. I will now try to poke around and reproduce what happened that caused that cache file to get so huge in the first place. It probably won't take long...
Please get back with any info you get on why the cache file was so huge.
I'm working on it. It's weird... I've spent many, many hours first trying to build connector, then trying to make it work, and I was running into so many problems making it work I thought it would be hopeless. But since deleting that cache file, it's running quite smoothly. Please keep this open for a bit longer, as given my prior problems I'm sure I'll be able to reproduce it...
Ok, it happened again. I went to create a meeting. I clicked Add to add a meeting partcipant. I typed in the first few letters of the person's name in the "Attendees" list, and clicked Enter. Evolution hung. For a long time... but no memory leak on exchange-storage. I then went through a series of restarts, hangs, and crashes/memory leaks of evolution-exchange-storage. I removed the cache.ics file, which had grown to 33meg, and even then it took a series of restarts before it went back to normal. Now I can setup the meeting normally, but I can't reproduce it. My cache.ics file is 1.5meg... I guess I'll just keep monitoring it and see when it grows again. What is this file caching?
The cache is the local copy of the icalendar objects retrieved from the server. Looks like you have quite a lot of appointments, or exchange is going on a nasty loop creating something wrong in the cache. Its a text file, so you can view it in an editor. See the file when exchange works fine and also when it misbehaves, and see if you can find out something suspicious. If i can ftp that cache file once it grows large would also help. I am not closing this bug. But, for now, i am moving this to 2.1 [ Also, as you mentioned in your other bug, you were using 1.5.93 version of connector, try using the latest one 1.5.94 ]
Reopening so we don't loose track of this one.
Created attachment 44306 [details] Screen shot of evolution-exhange-storage consuming large amounts of memory
I am experience a similar problem after upgrading to Evolution 2.0.1 on Fedora Core 2 using the packages from the yum repository at: [evolution2] name=Evolution 2.0 for Fedora Core 2 baseurl=http://petrix.se/evolution2 The packages now installed are: evolution-2.0.1-0.mozer.2 evolution-connector-debuginfo-1.4.7-5 evolution-data-server-1.0.1-0.mozer.1 evolution-connector-2.0.0-0.mozer.2 The comment above shows this problem in action. In my case this behavior began after I accepted a meeting request. Within a matter of seconds the service began to consume hundreds of MB or RAM until there was no more resources. The service eventually crashes. However, I cannot open Evolution anymore because as soon as I do the rampage immediately starts.
Hmmmm.... dunno if it has an impact, but you have 2.0.0 of connector, not 2.0.1. How big is your cache.ics file? Do: # cd ~/.evolution # ls -l `find . -name cache.ics` Also, do something similar to what I did in the bug report: start evolution like this: # gdb evolution-2.0 (gdb) run then once the process starts to consume lots of memory, in gdb stop it with Ctrl-c, and do "thread apply all bt" to get a stack trace, and include it in this bug report. I'm sure the developers will want some other info too.
I am also having this problem on FC2. I am running these versions of evolution from fedora: evolution-2.0.2-1 evolution-connector-2.0.2-1 evolution-data-server-1.0.2-3 evolution-data-server-devel-1.0.2-3 evolution-webcal-1.0.10-1 The first time the memory problem happened I noticed my cache file size was 140m. I deleted it and then it ran for a few days, but then I accepted another meeting (that had the same time period) and it started eating memory again. The cache file got to 89meg after I let it run until the evolution-exhange-storage stopped using CPU. The evolution-exhange-storage process had 873meg resident with 1461meg vitrual. After deleting the cache.ics again, it recreated to 176k initially. It then grew to 640k over the next 1/2 hour and has stopped for the time being. I did have recurring appointments with no end date before this restart - but I deleted them just in case they were the problem. My exchange calendar size was 641k befoer deleting the recurring appointments and 571k after(from outlook folder size).
This bug stopped happening for a while ago. I have no idea why it started or why it stopped. BTW, where did you get the FC2 packages for evolution?
Created attachment 44351 [details] Repeating Appt that causes large memory problem and large cache
Got the FC2 packages from the development branch. (http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/) I know this is considered unstable, but I reported it anyway since it seemed to be happening to others (bug 268246 as well). BTW. My cache has grown to 22meg over the last couple of days (process at 361m virtual, 305m res, 22m shr) I have only added 4 appointments since the last post. I am looking into the cache file and finding that one appt in particular is repeating. It says there are 9305 appts in there - based on counting the SUMMARY: or BEGIN:VEVENT lines - 9216 of them are the one that repeated. That particular one was an update to a recurring meeting. I am going to take the easy way out delete it from outlook. Attached is the original appt and its 9216 updates. (person/email info has been changed)
Okay the size of my cache.ics for my Exchange calendar is 43,542,175. The size for my cache.ics associated with my Exchange "tasks" is 1156. I have already upgraded to Evolution 2.0.2 and am still seeing the same problem. Now I will run it with gdb and try to get a stack trace.
Backtrace as requested: Program received signal SIGINT, Interrupt. [Switching to Thread -151137632 (LWP 27690)] 0x0028b7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) thread apply all bt
+ Trace 51387
Thread 12 (Thread -165680208 (LWP 27731))
Thread 11 (Thread -155190352 (LWP 27730))
Thread 10 (Thread 130366384 (LWP 27729))
Thread 9 (Thread 107543472 (LWP 27728))
Thread 8 (Thread 86412208 (LWP 27727))
Thread 7 (Thread 28330928 (LWP 27726))
Thread 4 (Thread 58670000 (LWP 27704))
Thread 2 (Thread 119876528 (LWP 27701))
Thread 1 (Thread -151137632 (LWP 27690))
I have not had the problem since I removed the updates to any repeating appointments from the outlook side and then deleted the cache.ics file. It was simple to identify problem appt in the cache.ics file by grepping out the summaries (SUMMARY:) that repeat and looking at the details of any one of them. Once the appt is removed, the problem seems to go away. I am not sure that it won't come back, but at least there is a workaround.
Bryan Christ: is it possible for you to gzip up the massively large cache.ics and make it available to me for further analysis? (and this applies to anyone else seeing this bug who hasn't yet deleted the file - or took a backup copy).
I saved my cache file (about 43M) and can make it available to you if this is still an issue. I'm running 2.0.3 so I guess this hasn't been fixed yet. I have been experiencing this problem since December when I started using evolution 2.x. My cache.ics file has grown to 43M, and caused evolution-exchange-storage to reach around 600M virtual size before I killed it (my poor laptop has only 512M). After moving the cache file out of the way, it seems to have quiesced with the cache file size rebuilt at about 3M, and evolution-exchange-storage at about 44M virtual size.
I just saw bug 270414 which claims this was fixed in 2.0.3. It may be that my corrupted cache file was lying around from before I was running 2.0.3 and was continuing to cause problems even though the root cause was fixed. If I experience the problem I'll update this bug. If I don't I'll try to remember to report that too so this bug can be closed. If you still want my cache file anyway, contact me.
OK, I'm an idiot. I'm still experiencing the problem, but now I see that bug 270414 does not claim the problem was fixed in 2.0.3 but rather has a patch that applies to 2.0.3 dated 20 Dec -- since 2.0.3 was released on 7 Dec obviously it isn't fixed in 2.0.3. I'll try the patch and stop filling up this bug report with my ramblings.
Changing state of bug to verified as this memory build up bug has been fixed in 2.0.3
I am using Evolution/Connector version 2.1.5 and the bug does indeed appear to be fixed.