Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I use Evolution as my Zimbra client. If I try to switch to the calendar view from the e.-mail view, overall performance suffers dramatically and it can take several minutes for the view to switch. Running top shows that e-calendar-fact is maxing the CPU. Sometimes this process has to be manually killed just to regain any degree of reasonable responsiveness from the machine. Version-Release number of selected component (if applicable): Evolution 2.32.1-1.fc14 (64 bit) How reproducible: Most of the time. Steps to Reproduce: 1. Launch Evolution (it having previously been configured as a Zimbra client.) 2. Accept a meeting invite that has been sent to you via email. 3. Swtich to calendar view. Actual results: Takes several minutes and makes entire OS extremely unresponsive. Running top shows that e-calendar-fact is monopolising on the CPU throughout that time. Expected results: A reasonable degree of responsiveness. Should switch to calendar view in a timely manner and not impact on performance of other applications. Additional info: I am subscribed to both my personal calendar and a shared team calendar on Zimbra.
*** Bug 659117 has been marked as a duplicate of this bug. ***
Thanks for a bug report. From the duplicate bug it does similar things when accepting invitation from one mail and updating status from the other mail, sent update on the same event by the same organizer.
Hrm, I don't seem to be able to reproduce this, I guess because my calendar is too small. Could you give me more information what calendar URL you have and to which you are accepting the meeting invitation/update, please? Also, if it takes long enough, could you install debug-info package for evolution-data-server and get backtrace of the running (and CPU chewing) e-calendar-factory, please? You can do that like this: $ gdb --batch --ex "t a a bt" -pid=PID &>eaf.bt where PID is a process ID of the running e-calendar-factory. Thanks in advance.
Thanks for the update. I tried to add those calendars, except of that yours, but no luck, no high CPU when moving to the calendar view after accepting a meeting invitation to another CalDAV calendar. It also doesn't matter whether the calendar factory was or wasn't running before I run evolution itself. To which addressbook are you accepting the invitation, please? I'm setting the need-info flag, because of waiting for the backtrace too.
I actually just received a meeting cancellation this morning and it seemed to max the CPU for a few moments. It wasn't as bad as the other day but I took a few successive traces for you to analyse. Will attach them now.
Created attachment 465080 [details] Batcktrace 1
Created attachment 465081 [details] Backtrace 2
Created attachment 465082 [details] Backtrace 3
I just had a friend send me some meeting invitations just to my personal calendar and I am getting the same error consistently from the backtraces now. e-calendar-factory is currently using 99.6% of the CPU according to top. I will attach three more backtraces to show what is happening in a moment.
Created attachment 465088 [details] bactkrace after item sent to personal calendar - same error
Created attachment 465089 [details] Backtrace a few moments later
Created attachment 465090 [details] Backtrace now e-calendar-factory is using 99.6% of CPU
Switching to calendar view and then back to email view a few minutes later also sends e-calendar-factory up to 99.7% CPU and produces the error again:
Created attachment 465095 [details] Switching to calendar view and back.
Thanks for the update. There seems to be something wrong with the command, because the files are only 180 bytes long, and apparently doesn't contains the backtrace, it contains only: > /usr/libexec/e-calendar-factory.#prelink#.AY9qCN (deleted): No such file or > directory. > > Thread 1 (process 2664): > #0 0xd18db0b3 in ?? () > Cannot access memory at address 0xc78ae290 Maybe an incorrect PID used in the gdb command?
Hello Milan, No, it was definitely the correct PID for the e-calendar-fact. It was the PID that was clocking up to 99.7% CPU use at the time the gdb traces were taken. Yes, I was surprised too that each trace contained so little data. I will do some more tests today and see what I can find out.
I have just restarted the process. This is the trace when it is running afresh, without having accepted or declined any meeting invitations:
Created attachment 467314 [details] Backtrace when process newly started - this contains more info
(In reply to comment #19) > Created attachment 467314 [details] > Backtrace when process newly started - this contains more info Yup, this one is better, it shows that the factory is idle, awaiting commands.
I've taken a series of debug traces this morning. Note that I have not had any real performance issues yet but you can take a look at these to see what it is doing.
Created attachment 467595 [details] Updating a meeting
Created attachment 467596 [details] Updating a meeting 2
Created attachment 467597 [details] Accepting a meeting
Created attachment 467598 [details] Accepting a meeting 2
Created attachment 467599 [details] Switching to calendar view and back.
Created attachment 467600 [details] Switching to calendar view and back 2.
Created attachment 467601 [details] Opening a meeting in the calendar
- comment #22: Two CalDAV calendars are idle, and the On The Web calendar is updating the view (telling evolution which events are available and which are not). - comment #23: One CalDAV is idle, the other is fetching objects from the server; the On The Web calendar is updating its content after it received events from the server - comment #25: Factory is idle. - comment #24: - comment #26: - comment #27: - comment #28: Both CalDAV calendars are idle, On The Web calendar is starting a new view From that I understand that your only WebCal is pretty large, but why it didn't exhibit any large timeouts for me I do not know. How large is yours ~/.cache/evolution/calendar/<webcal>/caledanr.ics file, please? Mine has something slightly more than 1 MB.
The WebCal is 1.1 Mb. I took another debug trace this morning and, for what it is worth, it is reporting that the debug info is now out of synch:
Created attachment 467863 [details] Debug info out of synch - CRC error
- comment #31: The CalDAV calendars are idle, On The Web calendar just tried a refresh and is parsing it. OK, so this is all about the webcal calendar. No need for more backtraces. Is your refresh time set on this calendars so small that it refreshes its content so often? Though it might not explain why you see it and I do not. I do something wrong, most likely.
Hrm, I thought this [1] would be related, but you are having evolution-data-server 2.32.1, so it might not be it. The question about refresh-time still holds. [1] https://bugzilla.gnome.org/show_bug.cgi?id=630265
The refresh time for the calendar is set to 30 minutes. I have found out something, though. I exited Evolution this morning (simply by clicking the window close button in the top-right corner of Metacity). Evolution seemed to exit properly by e-calendar-factory kept running. I left it for several minutes and the process did not end. I then restarted Evolution and the same e-calendar-factory process was still running. ps aux|grep calendar confirmed that it was the only calendar process (no new one had started for the new Evolution session.) It was at this point that extreme performance issues began to occur again.
Aha, that's it, having the calendar factory opened, be sure the webcal was opened even before, then the new evolution start, which opens the calendar, also refreshes webcal content, which eats CPU. It's for less than two seconds for me, but it's visible on the system monitor, thus OK, I'm confirming this and moving it upstream to [1]. Thanks a lot for helping to investigate this. [1] https://bugzilla.gnome.org/show_bug.cgi?id=420813