Bug 1293073 - Hi CPU load by evolution-calendar-factory-subprocess
Hi CPU load by evolution-calendar-factory-subprocess
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
23
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Milan Crha
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-19 17:50 EST by Iaroslav Prokopenko
Modified: 2017-05-24 11:45 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 12:11:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
evolution-source-registry (12.96 KB, text/plain)
2016-01-22 15:49 EST, Iaroslav Prokopenko
no flags Details
evolution-calendar-factory-subprocess (99.68 KB, text/plain)
2016-01-22 15:51 EST, Iaroslav Prokopenko
no flags Details

  None (edit)
Description Iaroslav Prokopenko 2015-12-19 17:50:00 EST
Description of problem:
Process causes 18-25% CPU load.
Also there is evolution-source-registry process with ~10% CPU load

Version-Release number of selected component (if applicable):
evolution-data-server-3.18.3-1.fc23.x86_64

How reproducible:
Checking

Steps to Reproduce:
Starts from some moment

Actual results:
CPU load, laptop heats up without any useful load

Expected results:
Assume process should not consume CPU in background

Additional info:
top command snapshot
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2848 vader     20   0 3409508  99900  32304 S  18.6  1.7  19:37.76 /usr/libexec/evolution-calendar-factory-subprocess --factory caldav --bus-name o+ 
 2558 vader     20   0 1596492  47536  34160 S  10.3  0.8  10:47.06 /usr/libexec/evolution-source-registry

[vader@tyche ~]$ cat /proc/2848/cmdline 
/usr/libexec/evolution-calendar-factory-subprocess--factorycaldav--bus-nameorg.gnome.evolution.dataserver.Subprocess.Backend.Calendarx2681x2--own-path
Comment 1 Iaroslav Prokopenko 2015-12-21 15:19:49 EST
I'm using Fedora Gnome desktop, Each time after system restart first user session logon causes this issue to be reproduced. Issue could be resolved after user performs logout and login again.
Comment 2 Milan Crha 2016-01-19 11:48:39 EST
Thanks for a bug report. Hard to tell what the high CPU causes without getting a backtrace or something of it. The only thing visible is it's one (or more) of your CalDAV calendars.

Could you install debuginfo package for the evolution-data-server (only that one, no need to install other debuginfo packages for its dependencies), then reproduce the issue and get backtraces of the two processes, when they'll use the high CPU, please? You can get the backtrace with a command like this:
   $ gdb --batch --ex "t a a bt" -pid=PID &>btPID.txt
Where you'll replace the PID with a concrete 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).

That may help to identify what the calendar, or the source registry, is doing. Thanks in advance.
Comment 3 dac.override 2016-01-21 14:54:09 EST
I encountered similar issue.

However as soon as i start gnome-calendar, evolution-data-center drops load to normal. (so maybe gnome-calendar is related)

gnome-calender itself is also a resource hog, when on the foreground it consumes 20% cpu and causes xserver and gnome-shell to do the same...
Comment 4 Iaroslav Prokopenko 2016-01-22 15:49 EST
Created attachment 1117335 [details]
evolution-source-registry

  PID TTY      STAT   TIME COMMAND
 2423 ?        Sl    12:04 /usr/libexec/evolution-source-registry
Comment 5 Iaroslav Prokopenko 2016-01-22 15:51 EST
Created attachment 1117336 [details]
evolution-calendar-factory-subprocess

  PID TTY      STAT   TIME COMMAND
 2725 ?        Sl    21:30 /usr/libexec/evolution-calendar-factory-subprocess --factory caldav --bus-name org.gnome.evolution.dataserver.Subprocess.Ba
Comment 6 Iaroslav Prokopenko 2016-01-22 16:01:24 EST
Hi Milan,

Thank you for the follow-up, sorry for the late response
Please find files attached, hope they will show who is the guilty=)
Cpu utilization picture was like that:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2725 vader     20   0 2827976  99328  32288 S  70.9  1.7  17:54.99 evolution-calen
 2423 vader     20   0 1568632  47588  33988 R  38.7  0.8   9:55.54 evolution-sourc 

By the way is there a way to install debuginfo package for the single package? I have failed with this, did not find any suitable keys to do this.
I have used following command which installed about 6 Gigs for all dependencies
$ sudo dnf debuginfo-install evolution-data-server
Comment 7 dac.override 2016-01-24 13:05:50 EST
I get these in the log when it happens to me:

org.gnome.evolution.dataserver.Calendar7[2527]: (evolution-calendar-factory-subprocess:3015): libsoup-WARNING **: SoupMessage 0x7f641000a2b0 stuck in infinite loop?
Comment 8 Milan Crha 2016-01-25 10:23:50 EST
(In reply to Iaroslav Prokopenko from comment #4)
> evolution-source-registry

It shows all the threads idle, waiting for orders. It can by only a coincidence that it doesn't do anything at this moment.

(In reply to Iaroslav Prokopenko from comment #5)
> evolution-calendar-factory-subprocess

This one shows many threads, some resolving server addresses, some connecting to the server. How many CalDAV calendars do you have configured, please? It looks like at least 12 from the backtrace.

(In reply to Iaroslav Prokopenko from comment #6)
> $ sudo dnf debuginfo-install evolution-data-server

I use:
   $ dnf install evolution-data-server-debuginfo --enablerepo=*-debuginfo
and I make sure the downloaded version is the same as the binary package version. Eventually download it from the koji server:
http://koji.fedoraproject.org/koji/

where you can search for the package and pick the version you've installed, then download it and install it as:
   $ dnf install ./package.rpm
eventually
   $ dnf update ./package.rpm

(In reply to dac.override from comment #7)
> I get these in the log when it happens to me:
> 
> org.gnome.evolution.dataserver.Calendar7[2527]:
> (evolution-calendar-factory-subprocess:3015): libsoup-WARNING **:
> SoupMessage 0x7f641000a2b0 stuck in infinite loop?

Right, it can be related. I didn't see it myself yet. I'm wondering how that can be reproduced.
Comment 9 dac.override 2016-01-26 12:57:48 EST
It seems to start with:

org.gnome.evolution.dataserver.Sources5[2521]: ** (evolution-source-registry:2716): WARNING **: secret_service_search_sync: must specify at least one attribute to match

At that point calendar server starts flooding the logs with aforementioned message and start utilising 20% CPU

It seems to be related to my gmail account because that is mentioned when i kill -HUP it:

org.gnome.Shell.CalendarServer[2521]: (gnome-shell-calendar-server:2711): ShellCalendarServer-WARNING **: The calendar backend for 'dac.override@gmail.com' has crashed.

org.gnome.Shell.CalendarServer[2521]: (gnome-shell-calendar-server:2711): ShellCalendarServer-CRITICAL **: create_client_for_source: assertion 'client == NULL' failed
Comment 10 Milan Crha 2016-01-27 05:04:56 EST
I suppose you configured that account using GNOME Online Accounts. Could you verify in the Settings->Online Accounts, that the account is defined properly there? Aka there is not shown any issue or a request to reassign to it. Seahorse may also show you what passwords (credentials) you've stored, though the secret_service_search_sync() runtime warning suggests that there's something odd with the associated .source file in the evolution.
Comment 11 dac.override 2016-01-27 13:31:40 EST
The account seems to be configured properly, but i to be sure i re-did it a few times. Seahorse show the keys properly and i haven't noticed any anomalies there.

I also removed the ~/{.cache,.config,.local/share}/evolution a couple of times but no effects.

These "infinite loop messages" start happening two hours after i booted (like clockwork).
Comment 12 Milan Crha 2016-01-28 04:04:17 EST
(In reply to dac.override from comment #11)
> The account seems to be configured properly, but i to be sure i re-did it a
> few times.

Just in case, it is configured in GOA, not directly in the evolution, right?

> These "infinite loop messages" start happening two hours after i booted
> (like clockwork).

Do you mean like after the time you set the calendar's refresh interval to?

Could you check content of ~/.config/evolution/sources/ and ~/.cache/evolution/sources/ for the files referencing this concrete calendar (the file will have a [Calendar] section in it), sanitize it from any private information (like email addresses and server addresses) and then attach it here, thus I could check whether there isn't anything suspicious in its content, please?

I tried to setup a similar conditions as you have, and set a refresh interval to two hours for the Google calendar. Maybe I'll trigger it too. Otherwise my experience with gnome-calendar was different: when I run it, it ate significant part of CPU, until I closed it again.
Comment 13 dac.override 2016-01-28 04:22:44 EST
(In reply to Milan Crha from comment #12)
> (In reply to dac.override from comment #11)
> > The account seems to be configured properly, but i to be sure i re-did it a
> > few times.
> 
> Just in case, it is configured in GOA, not directly in the evolution, right?

Right, I do not have evolution installed. I use gnome-calendar for the calendar, gnome-contacts for contacts, and thunderbird and/or mutt for e-mail

> 
> > These "infinite loop messages" start happening two hours after i booted
> > (like clockwork).
> 

I mean when i boot up the system, then when i wait for 2 hours, the "infinite loop" messages start occuring and cpu usage surges. 

> Do you mean like after the time you set the calendar's refresh interval to?
> 
> Could you check content of ~/.config/evolution/sources/ and
> ~/.cache/evolution/sources/ for the files referencing this concrete calendar
> (the file will have a [Calendar] section in it), sanitize it from any
> private information (like email addresses and server addresses) and then
> attach it here, thus I could check whether there isn't anything suspicious
> in its content, please?

output of cat ~/.config/evolution/sources/*.source:

http://paste.fedoraproject.org/315655/39728631/

> 
> I tried to setup a similar conditions as you have, and set a refresh
> interval to two hours for the Google calendar. Maybe I'll trigger it too.
> Otherwise my experience with gnome-calendar was different: when I run it, it
> ate significant part of CPU, until I closed it again.
Comment 14 dac.override 2016-01-28 04:28:42 EST
As for gnome-calendar, yes with it on the foreground it runs up to 20% cpu and drags gnome-shell and xorg with it:

top:

 3106 kcinimod  20   0 2054120  62752  17224 S  29.9  0.8   0:29.64 evolution-calen                                        
 2840 kcinimod  20   0 1868164 137156  58724 R  22.3  1.7   0:39.48 gnome-shell                                            
 6128 kcinimod  20   0 1534472  41984  28804 R  21.9  0.5   0:05.64 gnome-calendar                                         
 2675 kcinimod  20   0  300156  55696  43564 S  18.3  0.7   0:33.37 Xorg        

When i put gnome-calendar in the background (another workspace) then xorg, gnome-shell and gnome-calendar with return to normal utilization
Comment 15 dac.override 2016-01-28 04:37:50 EST
snippet for just yet:

Jan 28 10:25:06 void org.gnome.evolution.dataserver.Sources5[2724]: ** (evolution-source-registry:2919): WARNING **: secret_service_search_sync: must specify at least one
 attribute to match
Jan 28 10:25:09 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3880022a0 stuck in
 infinite loop?

(... times N)

Jan 28 10:26:57 void /usr/libexec/gdm-x-session[2668]: Activating service name='org.gnome.Calendar'
Jan 28 10:26:57 void /usr/libexec/gdm-x-session[2668]: Successfully activated service 'org.gnome.Calendar'
Jan 28 10:26:57 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3a400c8c0 stuck in infinite loop?

(... times N)

Jan 28 10:27:32 void kernel: perf interrupt took too long (2540 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Jan 28 10:27:33 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3a400c8c0 stuck in infinite loop?

(... times N)
Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkWindow'
Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkWidget'
Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): Gtk-CRITICAL **: gtk_widget_get_window: assertion 'GTK_IS_WIDGET (widget)' failed
Jan 28 10:28:43 void kernel: gnome-calendar[6128]: segfault at 28 ip 0000560c3b7864c0 sp 00007fff0eb4ec68 error 4 in gnome-calendar[560c3b768000+54000]
Jan 28 10:28:43 void kernel: audit: type=1701 audit(1453973323.895:2479): auid=1000 uid=1000 gid=1000 ses=1 subj=wheel.id:wheel.role:wheel_gcal.subj:s0-s0:c0.c1023 pid=6128 comm="gnome-calendar" exe="/usr/bin/gnome-calendar" sig=11
Jan 28 10:28:43 void audit[6128]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=1 subj=wheel.id:wheel.role:wheel_gcal.subj:s0-s0:c0.c1023 pid=6128 comm="gnome-calendar" exe="/usr/bin/gnome-calendar" sig=11
Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): Gdk-CRITICAL **: gdk_window_get_state: assertion 'GDK_IS_WINDOW (window)' failed
Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GcalWindow'
Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): Gtk-CRITICAL **: gtk_window_get_application: assertion 'GTK_IS_WINDOW (window)' failed
Jan 28 10:28:44 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3a400caa0 stuck in infinite loop?

(... times N)
Jan 28 10:28:53 void systemd-coredump[6521]: Process 6128 (gnome-calendar) of user 1000 dumped core.
                                             
                                             Stack trace of thread 6128:
                                             #0  0x0000560c3b7864c0 gcal_application_get_settings (gnome-calendar)
                                             #1  0x0000560c3b789673 save_geometry (gnome-calendar)
                                             #2  0x00007fc49049b893 g_timeout_dispatch (libglib-2.0.so.0)
                                             #3  0x00007fc49049ae3a g_main_context_dispatch (libglib-2.0.so.0)
                                             #4  0x00007fc49049b1d0 g_main_context_iterate.isra.29 (libglib-2.0.so.0)
                                             #5  0x00007fc49049b27c g_main_context_iteration (libglib-2.0.so.0)
                                             #6  0x00007fc490a85a0c g_application_run (libgio-2.0.so.0)
                                             #7  0x0000560c3b77e0b0 main (gnome-calendar)
                                             #8  0x00007fc48f5ea580 __libc_start_main (libc.so.6)
                                             #9  0x0000560c3b77e0f9 _start (gnome-calendar)
                                             
                                             Stack trace of thread 6129:
                                             #0  0x00007fc48f6c0fdd poll (libc.so.6)
                                             #1  0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0)
                                             #2  0x00007fc49049b27c g_main_context_iteration (libglib-2.0.so.0)
                                             #3  0x00007fc48246f2ad dconf_gdbus_worker_thread (libdconfsettings.so)
                                             #4  0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0)
                                             #5  0x00007fc48fba960a start_thread (libpthread.so.0)
                                             #6  0x00007fc48f6cca4d __clone (libc.so.6)
                                             
                                             Stack trace of thread 6139:
                                             #0  0x00007fc48f6c0fdd poll (libc.so.6)
                                             #1  0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0)
                                             #2  0x00007fc49049b4f2 g_main_loop_run (libglib-2.0.so.0)
                                             #3  0x00007fc494e80673 cal_client_dbus_thread (libecal-1.2.so.19)
                                             #4  0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0)
                                             #5  0x00007fc48fba960a start_thread (libpthread.so.0)
                                             #6  0x00007fc48f6cca4d __clone (libc.so.6)
                                             Stack trace of thread 6130:
                                             #0  0x00007fc48f6c0fdd poll (libc.so.6)
                                             #1  0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0)
                                             #2  0x00007fc49049b27c g_main_context_iteration (libglib-2.0.so.0)
                                             #3  0x00007fc49049b2b9 glib_worker_main (libglib-2.0.so.0)
                                             #4  0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0)
                                             #5  0x00007fc48fba960a start_thread (libpthread.so.0)
                                             #6  0x00007fc48f6cca4d __clone (libc.so.6)
                                             
                                             Stack trace of thread 6131:
                                             #0  0x00007fc48f6c0fdd poll (libc.so.6)
                                             #1  0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0)
                                             #2  0x00007fc49049b4f2 g_main_loop_run (libglib-2.0.so.0)
                                             #3  0x00007fc490abc336 gdbus_shared_thread_func (libgio-2.0.so.0)
                                             #4  0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0)
                                             #5  0x00007fc48fba960a start_thread (libpthread.so.0)
                                             #6  0x00007fc48f6cca4d __clone (libc.so.6)
                                             
                                             Stack trace of thread 6133:
                                             #0  0x00007fc48f6c0fdd poll (libc.so.6)
                                             #1  0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0)
                                             #2  0x00007fc49049b4f2 g_main_loop_run (libglib-2.0.so.0)
                                             #3  0x00007fc493046a34 source_registry_object_manager_thread (libedataserver-1.2.so.21)
                                             #4  0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0)
                                             #5  0x00007fc48fba960a start_thread (libpthread.so.0)
                                             #6  0x00007fc48f6cca4d __clone (libc.so.6)
Jan 28 10:28:53 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff39003f8b0 stuck in infinite loop?

(...times N)

(me putting it out of its misery with kill -HUP PID)

Jan 28 10:30:49 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-WARNING **: The calendar backend for 'Feestdagen in Nederland' has crashed.
Jan 28 10:30:49 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-WARNING **: The calendar backend for 'Verjaardagen' has crashed.
Jan 28 10:30:49 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-WARNING **: The calendar backend for 'dac.override@gmail.com' has crashed.
Jan 28 10:30:51 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-CRITICAL **: create_client_for_source: assertion 'client == NULL' failed
Jan 28 10:30:52 void gnome-keyring-daemon[2619]: asked to register item /org/freedesktop/secrets/collection/login/16, but it's already registered
Jan 28 10:30:52 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-CRITICAL **: create_client_for_source: assertion 'client == NULL' failed
Comment 16 Milan Crha 2016-01-28 05:44:24 EST
(In reply to dac.override from comment #13)
> output of cat ~/.config/evolution/sources/*.source:

Thanks, though it's hard to recognize where one source starts and another ends. The file name is used as a unique identifier of it, thus they are sort of important too.

The files in ~/.cache/evolution/sources/<some-uid>/ are the respective associated sources for the GOA account, like the calendars.

The ~/.config/goa-1.0/accounts.conf contains [Account account_1453914525_1] section, which holds what you've enabled and what not and some user details. You might have it similar to what I have (with different account name), thus:

   [Account account_1445926770_0]
   Provider=google
   Identity=user@gmail.com
   PresentationIdentity=user@gmail.com
   MailEnabled=false
   CalendarEnabled=true
   ContactsEnabled=false
   ChatEnabled=false
   DocumentsEnabled=false
   PhotosEnabled=false
   FilesEnabled=false
   PrintersEnabled=false

I see one difference in what you have in the pastebin and what I have in the same .source file (that with [GNOME Online Account] section). Your file contains
   [Authentication]
   Host=
   Method=none
while mine has that
   [Authentication]
   Host=
   Method=OAuth2

The Method=none is not correct for GOA accounts accessing Google, it should read OAuth2. The calendar source (in ~/.cache/evolution/sources/<uid>) can have it differently. I have there OAuth2 too.
Comment 17 Alexey Brodkin 2016-03-16 10:34:14 EDT
I had configured Google account in Gnome's "Online accounts" and at some point (like a day or 2 ago) started to see evolution-calendar-factory-subprocess consuming ~25% of CPU plus other related (?) processes were eating other CPUs as well. Now I disabled all items in that "Online Account" (i.e. I didn't deleted it but nothing gets synced now) and magically all extra CPU loads went away.
Comment 18 Fedora End Of Life 2016-11-24 09:22:51 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Fedora End Of Life 2016-12-20 12:11:19 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 20 Thomas Vollstädt 2017-05-18 20:16:12 EDT
Hi,

I'm experiencing exactly the same issue on a regular basis (feels like every one-two days).

* Fedora 26 Alpha
* Evolution 3.24.2-1.fc26

I'm not actively using Evolution when I get aware of the issue, but I think I used it some time before. I only get notified by a loud CPU fan.

Just killed the process, but here are some pastes:

Output of ~/.local/evolution/sources/*.source: https://pastebin.com/eh8hpXxB
Output of ~/.cache/evolution/sources/*.source: https://pastebin.com/ZhiLwjy1

I configured the mail accounts through "Online Accounts" at first, which caused strange issues like freezing Evolution completly. Now I configured the accounts through Evolution directly, which works much better (but still not perfect).

Just let me know if I can provide more information.
Comment 21 Milan Crha 2017-05-19 01:07:53 EDT
Thanks for the update. If I read it properly, then you've an EWS account and and IMAPx account and that EWS account contains quite many address books, one memo list, one task list, and like 5 calendars.

I suppose the high CPU usage is caused by the EWS calendars, but to be sure a:

   $ ps ax | grep evolution

shows also arguments for the binaries, where --factory argument for an evolution-calendar-factory-subprocess tells which of them is running in it.

After that, a backtrace of the running high-CPU-consuming process would be nice to have, even several of them, to see what it does or tries to do. Comment #2 contains a gdb command to do so. Please, install also debuingo package for evolution-ews, apart of evolution-data-server mentioned there, thus the backtrace is usable.
Comment 22 Milan Crha 2017-05-23 02:50:25 EDT
I made this [1] change for evolution-data-server 3.24.3+. I cannot tell whether it'll help in your case (because I do not know what that issue is), but it is supposed to help in an instance of the issue I accidentally faced.

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=d4d9f16
Comment 23 Thomas Vollstädt 2017-05-23 05:59:18 EDT
I played with my calenders and address books, but I'm currently unable to reproduce the issue. Should I be successfull, I will provide your requested debug data and try your patch (thanks for that!). 

One different issue I found though is that activating other calenders (from collegues) will add those appointments to my system calender and reminders... which is in theory correct, but there should be an option to prevent that (I sometimes just want to look around in other calenders of my company). But this is surely another issue.
Comment 24 Milan Crha 2017-05-23 06:51:53 EDT
(In reply to Thomas Vollstädt from comment #23)
> One different issue I found though is that activating other calenders (from
> collegues) will add those appointments to my system calender and
> reminders... which is in theory correct, but there should be an option to
> prevent that (I sometimes just want to look around in other calenders of my
> company). But this is surely another issue.

Edit->Preferences->Calendar and Tasks->Reminders tab - check which to use for reminders and which not. Calendar view itself is clear, you can check/uncheck calendars there, and see only those checked.
Comment 25 Thomas Vollstädt 2017-05-24 10:28:03 EDT
(In reply to Milan Crha from comment #24)
> Edit->Preferences->Calendar and Tasks->Reminders tab - check which to use
> for reminders and which not. Calendar view itself is clear, you can
> check/uncheck calendars there, and see only those checked.

Unfortunately this doesn't work on my setup, appointments of unchecked calendars are still shown in the notification area of gnome-shell. Should I create a new ticket for this?

Still no appearance of the original issue, I will keep an eye on it.
Comment 26 Milan Crha 2017-05-24 11:45:34 EDT
(In reply to Thomas Vollstädt from comment #25)
> Unfortunately this doesn't work on my setup, appointments of unchecked
> calendars are still shown in the notification area of gnome-shell. Should I
> create a new ticket for this?

Not needed, it means that it's another software showing the notifications. I do not know how to figure out which it is, though.

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