Bug 1148247 - Why evolution-calendar-factory eat much CPU?
Summary: Why evolution-calendar-factory eat much CPU?
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 26
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: Milan Crha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-01 04:10 UTC by Mikhail
Modified: 2018-02-06 10:33 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-06 10:33:08 UTC
Type: Bug


Attachments (Terms of Use)
backtrace of evolution (2.70 KB, application/x-gzip)
2014-10-01 04:10 UTC, Mikhail
no flags Details
screenshot of htop (296.54 KB, image/png)
2014-10-01 04:10 UTC, Mikhail
no flags Details
GOA settings (241.12 KB, image/png)
2014-10-01 18:26 UTC, Mikhail
no flags Details
new backtraces (9.88 KB, application/x-gzip)
2014-10-12 09:03 UTC, Mikhail
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 738545 0 Normal RESOLVED Busy loop under task_thread_cancelled() 2020-09-16 17:33:28 UTC

Description Mikhail 2014-10-01 04:10:30 UTC
Created attachment 942909 [details]
backtrace of evolution

Description of problem:
Why evolution-calendar-factory eat much CPU?

Comment 1 Mikhail 2014-10-01 04:10:57 UTC
Created attachment 942910 [details]
screenshot of htop

Comment 2 Milan Crha 2014-10-01 08:27:51 UTC
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?

Comment 3 Mikhail 2014-10-01 18:25:41 UTC
(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

Comment 4 Mikhail 2014-10-01 18:26:35 UTC
Created attachment 943180 [details]
GOA settings

Comment 5 Mikhail 2014-10-12 09:03:00 UTC
Created attachment 946075 [details]
new backtraces

Comment 6 Mikhail 2014-10-12 09:07:32 UTC
It's happens again after reboot (I am not run evollution)

Demo: https://drive.google.com/file/d/0B0nwzlfiB4aQU1FVeXpUdmpFeGM/view?usp=sharing

Comment 7 Mikhail 2014-10-12 09:18:07 UTC
> 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.

Comment 8 Milan Crha 2014-10-13 11:03:58 UTC
(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.

Comment 9 Mikhail 2014-10-13 13:18:53 UTC
> 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.

Comment 10 Milan Crha 2014-10-14 06:16:41 UTC
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.

Comment 11 Christian Stadelmann 2014-11-04 09:36:57 UTC
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.

Comment 12 Milan Crha 2014-11-05 07:11:58 UTC
(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).

Comment 13 James (purpleidea) 2014-11-25 13:49:58 UTC
I still have this issue in F20 as of today...

Comment 14 Milan Crha 2014-11-26 07:03:01 UTC
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).

Comment 15 James (purpleidea) 2014-11-26 15:15:24 UTC
(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.

Comment 16 James (purpleidea) 2018-02-06 10:24:14 UTC
Still a major issue in F26!!

Worst of all it respawns when you kill it!

Comment 17 Milan Crha 2018-02-06 10:33:08 UTC
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).


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