Created attachment 942909 [details] backtrace of evolution Description of problem: Why evolution-calendar-factory eat much CPU?
Created attachment 942910 [details] screenshot of htop
Thanks for a bug report. The calendar factory process currently (at your backtrace) tries to see whether certain addresses are available, to decide whether respective calendars should be turned online or offline. One CalDAV calendar is connected and checking whether the calendar changed. What CalDAV calendars do you have configured, please? It can be either directly CalDAV calendar, or a Google calendar. Did you configure that calendar through Evolution, or through GNOME Online Accounts? I would try to disable the calendar part in GOA, if it's from there, just to see whether it'll help. Also, what is your version of evolution-data-server package, please?
(In reply to Milan Crha from comment #2) > Thanks for a bug report. The calendar factory process currently (at your > backtrace) tries to see whether certain addresses are available, to decide > whether respective calendars should be turned online or offline. One CalDAV > calendar is connected and checking whether the calendar changed. What CalDAV > calendars do you have configured, please? It can be either directly CalDAV > calendar, or a Google calendar. Google calendar and non working (Expired password) Exchange calendar > Did you configure that calendar through > Evolution, or through GNOME Online Accounts? I am configure calendar through GNOME Online Accounts > I would try to disable the calendar part in GOA, if it's from there, > just to see whether it'll help. Ok, next time I try to check this. > Also, what is your version of evolution-data-server package, please? $ rpm -qa | grep evolution evolution-ews-debuginfo-3.12.6-1.fc21.x86_64 evolution-data-server-debuginfo-3.12.6-1.fc21.x86_64 evolution-3.12.6-1.fc21.x86_64 evolution-debuginfo-3.12.6-1.fc21.x86_64 evolution-data-server-3.12.6-1.fc21.x86_64 evolution-ews-3.12.6-1.fc21.x86_64 evolution-help-3.12.6-1.fc21.noarch
Created attachment 943180 [details] GOA settings
Created attachment 946075 [details] new backtraces
It's happens again after reboot (I am not run evollution) Demo: https://drive.google.com/file/d/0B0nwzlfiB4aQU1FVeXpUdmpFeGM/view?usp=sharing
> I would try to disable the calendar part in GOA, if it's from there, > just to see whether it'll help. Disabling calendar part in GOA not helps imminently.
(In reply to Mikhail from comment #6) > It's happens again after reboot (I am not run evollution) This looks just like bug #1151665, I suspect some change in GLib causing trouble here. (In reply to Mikhail from comment #7) > Disabling calendar part in GOA not helps imminently. I see. In this particular updated backtrace the issue was in addressbook factory, for which an addresbook part is involved, but because of bug #1151665 showing pretty similar backtrace I'd guess this issue lies lower in the stack, in GLib. But let's see what will be discovered at bug #1151665 first.
> I'd guess this issue lies lower in the stack, in GLib # debuginfo-install glibc Loaded plugins: auto-update-debuginfo, langpacks enabling rpmfusion-nonfree-rawhide-debuginfo enabling rpmfusion-free-rawhide-debuginfo Package glibc-debuginfo-2.20-5.fc21.x86_64 already installed and latest version Package nss-softokn-debuginfo-3.17.1-2.fc21.x86_64 already installed and latest version No debuginfo packages available to install You don't see glibc in backtrace? Strange all debug symbols are installed.
The GLib is packaged as glib2 and you have that debug info installed, because the backtrace shows source files with line numbers, aka very nice backtrace. I'd wait for Glib developers for their input on this issue, either here or in bug #1151665.
Same problem here: evolution-calendar-factory often (not always) uses 100% CPU from the time I login. When running evolution to view calendars, all of them (no matter whether they are local or on the web, not using gnome-online-accounts) except the birthday calendar time out. California shows them all but only after spending ~5…10 Minutes running in background with no window visible. The NetworkManager update (see [1]) claims to fix this bug but doesn't. I have reported this bug upstreams to [2] and it seems to be a bug in debian [3] either. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1151665 [2] https://bugzilla.gnome.org/show_bug.cgi?id=738545 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755981 This bug renders evolution's calendar view completely useless, reminders don't work at all, the gnome-shell calendar view does not display any events and california is barely usable because it takes so long.
(In reply to Christian Stadelmann from comment #11) > This bug renders evolution's calendar view completely useless, reminders > don't work at all, the gnome-shell calendar view does not display any events > and california is barely usable because it takes so long. Makes sense. When the "server" is busy, then any client connecting to it will suffer of a similar issues. Let's move to the upstream bug. There's always a chance that the handling on the evolution-data-server (evolution-calendar-factory) side is wrong. I do not know how much it is related to the network manager bug, but it seems it can be. It would be good to try the test build from bug #1151665, instead of the official update, just to test whether the test build will fix anything (like if the official update didn't break more things).
I still have this issue in F20 as of today...
I guess you mean Fedora 21, not Fedora 20. In any case, it makes sense, the upstream bug isn't fixed yet (move there, please).
(In reply to Milan Crha from comment #14) > I guess you mean Fedora 21, not Fedora 20. In any case, it makes sense, the > upstream bug isn't fixed yet (move there, please). My mistake, moved there. Thanks.
Still a major issue in F26!! Worst of all it respawns when you kill it!
There's a really big gap between Fedora 21 and Fedora 26, not talking that the latest (and highly changed) calendar and address book code is in Fedora 27, thus 3.26.x. I doubt this is the same issue as that 4 years ago. Open a new bug report and provide backtraces of the affected processes, please, to see what it does. make sure you do not expose any private information in them; also make sure you'll have installed debuginfo packages for evolution-data-server and evolution at least, of exactly the same version as their binary package counterparts. You can get the backtrace with command like this: $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt where PID is replaced with respective process ID. Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).