Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1346228 - CalDAV fails to recognize "Daily Limit Exceeded" error from Google/GOA
Summary: CalDAV fails to recognize "Daily Limit Exceeded" error from Google/GOA
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution-data-server
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Milan Crha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-14 10:16 UTC by Matthias Runge
Modified: 2016-12-13 16:31 UTC (History)
11 users (show)

Fixed In Version: evolution-data-server-3.20.5-3.fc24 evolution-data-server-3.20.5-4.fc24 evolution-data-server-3.20.5-5.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-13 21:53:42 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
gstack pid of goa-daemon with high cpu consumption (5.06 KB, text/plain)
2016-07-12 07:02 UTC, mrummuka 		no flags Details
Several backtraces from goa-daemon (gstack) (30.00 KB, application/x-tar)
2016-08-09 06:46 UTC, Soeren Grunewald 		no flags Details
goa-daemon strace log (747.32 KB, text/plain)
2016-08-10 06:06 UTC, Soeren Grunewald 		no flags Details
gstack with goa-daemon running and all accounts/services enabled (4.10 KB, text/plain)
2016-08-10 08:51 UTC, avitygrai 		no flags Details
strace with goa-daemon running and all accounts/services enabled (35.04 KB, text/plain)
2016-08-10 08:59 UTC, avitygrai 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 771547 0 None None None 2016-12-13 16:31:07 UTC
GNOME Bugzilla 773248 0 None None None 2016-12-13 16:31:31 UTC

Description Matthias Runge 2016-06-14 10:16:17 UTC 
Description of problem:

it seems, the version gnome-online-accounts-3.20.1-1.fc24.x86_64

uses a lot more cpu cycles that it should:
in top, it constantly uses more than 15%, often reaching 40%

When I kill it, it'll respawn, reaching the same cpu usage.

Please provide some info to debug this further.
Comment 1 Debarshi Ray 2016-06-14 13:17:22 UTC 
How about:
$ gstack <pid-of-goa-daemon>

If you take a few backtraces like that, then it might reveal something interesting.
Comment 2 Matthias Runge 2016-06-24 06:07:42 UTC 
Can't reproduce any more.
Comment 3 mrummuka 2016-07-12 07:02:23 UTC 
Created attachment 1178753 [details]
gstack pid of goa-daemon with high cpu consumption

Hi,
after encountering high cpu consumption with goa-daemon and googling for known issues I stumbled upon this thread. The same phenomenon (20-50% CPU eaten) seems to be occurring right now in my Fedora 24 installation with latest updates, with 2FA Google and MS accounts set up for online accounts. 

Added an attachment of gstack <pid of goa-daemon> with high cpu consumption, hopefully it helps.
Comment 4 Debarshi Ray 2016-07-12 16:40:10 UTC 
(In reply to mrummuka from comment #3)
> Added an attachment of gstack <pid of goa-daemon> with high cpu consumption,
> hopefully it helps.

If you take a few backtraces with gstack during high CPU consumption, do they consistently represent something similar?
Comment 5 Debarshi Ray 2016-07-12 16:50:06 UTC 
(In reply to Debarshi Ray from comment #4)
> (In reply to mrummuka from comment #3)
> > Added an attachment of gstack <pid of goa-daemon> with high cpu consumption,
> > hopefully it helps.
> 
> If you take a few backtraces with gstack during high CPU consumption, do
> they consistently represent something similar?

I am asking because attachment 1178753 [details] says that five threads are idly waiting, while thread #6 is doing some network I/O over TLS and also waiting for some data to come in. I don't know how this can consume a lot of CPU.
Comment 6 Debarshi Ray 2016-07-12 16:54:21 UTC 
(In reply to Debarshi Ray from comment #5)
> I am asking because attachment 1178753 [details] says that five threads are
> idly waiting, while thread #6 is doing some network I/O over TLS and also
> waiting for some data to come in. I don't know how this can consume a lot of
> CPU.

Ok, TLS can cost some CPU due to the cryptography involved, but it shouldn't consume that much unless some application is aggressively calling EnsureCredentials in a tight loop. Even then, since version 3.18.3 we coalesce EnsureCredentials calls on the same account so that even if N such calls came in while one was being processed, we won't issue N+1 network calls.
Comment 7 mrummuka 2016-07-16 09:38:15 UTC 
OK - I'll try to capture a few backtraces different times, however, at the moment the cpu consumed by goa-daemon seems to be zero so I'll need to see if the situation is reproduced later.
Comment 8 Soeren Grunewald 2016-08-09 06:46:25 UTC 
Created attachment 1189046 [details]
Several backtraces from goa-daemon (gstack)

Same issue here, see attached back-traces
Comment 9 Debarshi Ray 2016-08-09 15:41:11 UTC 
(In reply to Soeren Grunewald from comment #8)
> Created attachment 1189046 [details]
> Several backtraces from goa-daemon (gstack)
> 
> Same issue here, see attached back-traces

Thanks for the backtraces.

For the sake of those who might be following along, they look like this:


Thread 6 (Thread 0x7f51fbfff700 (LWP 1300)):
#0  0x00007f52106f9ff9 in syscall () at /lib64/libc.so.6
#1  0x00007f5210fd2dca in g_cond_wait_until () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f63489 in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007f5210fb570a in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 5 (Thread 0x7f51fa7fc700 (LWP 1203)):
#0  0x00007f51f947a15e in _gnutls_base64_decode () at /lib64/libgnutls.so.30
#1  0x00007f51f947a54e in _gnutls_fbase64_decode () at /lib64/libgnutls.so.30
#2  0x00007f51f94d80aa in gnutls_x509_crt_import () at /lib64/libgnutls.so.30
#3  0x00007f51f94dbe45 in gnutls_x509_crt_list_import () at /lib64/libgnutls.so.30
#4  0x00007f51f94dc177 in gnutls_x509_crt_list_import2 () at /lib64/libgnutls.so.30
#5  0x00007f51f94e30d9 in gnutls_x509_trust_list_add_trust_mem () at /lib64/libgnutls.so.30
#6  0x00007f51f94e34af in gnutls_x509_trust_list_add_trust_file () at /lib64/libgnutls.so.30
#7  0x00007f5211267a36 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#8  0x00007f52112695ee in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#9  0x00007f5211502206 in g_initable_new_valist () at /lib64/libgio-2.0.so.0
#10 0x00007f52115022c6 in g_initable_new () at /lib64/libgio-2.0.so.0
#11 0x00007f521189eb74 in soup_session_set_property () at /lib64/libsoup-2.4.so.1
#12 0x00007f5211269bbb in g_object_set_valist () at /lib64/libgobject-2.0.so.0
#13 0x00007f521126a37c in g_object_set () at /lib64/libgobject-2.0.so.0
#14 0x00007f5211b0b374 in rest_proxy_init () at /lib64/librest-0.7.so.0
#15 0x00007f52112858c1 in g_type_create_instance () at /lib64/libgobject-2.0.so.0
#16 0x00007f52112676ab in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#17 0x00007f52112695ee in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#18 0x00007f52112698a1 in g_object_new () at /lib64/libgobject-2.0.so.0
#19 0x00007f5217739f20 in get_identity_sync () at /lib64/libgoa-backend-1.0.so.1
#20 0x00007f52177398e7 in goa_oauth2_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#21 0x00007f521772c1ba in goa_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#22 0x00007f521772c26d in ensure_credentials_in_thread_func () at /lib64/libgoa-backend-1.0.so.1
#23 0x00007f5211519b81 in run_in_thread () at /lib64/libgio-2.0.so.0
#24 0x00007f5211505ae9 in io_job_thread () at /lib64/libgio-2.0.so.0
#25 0x00007f521152bb10 in g_task_thread_pool_thread () at /lib64/libgio-2.0.so.0
#26 0x00007f5210fb5735 in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#27 0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#28 0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#29 0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7f51faffd700 (LWP 1202)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f52001f8fad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7f51fb7fe700 (LWP 1201)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f5211587f76 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7f5200bff700 (LWP 1199)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f5210f8eba1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7f5217d02ac0 (LWP 1198)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x000055cd38e9c07d in main ()


Thread 6 (Thread 0x7f51fbfff700 (LWP 1300)):
#0  0x00007f52106f9ff9 in syscall () at /lib64/libc.so.6
#1  0x00007f5210fd2dca in g_cond_wait_until () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f63489 in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007f5210fb570a in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 5 (Thread 0x7f51fa7fc700 (LWP 1203)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f521151ca35 in g_socket_condition_timed_wait () at /lib64/libgio-2.0.so.0
#2  0x00007f521151d95a in g_socket_receive_with_timeout () at /lib64/libgio-2.0.so.0
#3  0x00007f5211503af4 in g_input_stream_read () at /lib64/libgio-2.0.so.0
#4  0x00007f51f9778b45 in g_tls_connection_gnutls_pull_func () at /usr/lib64/gio/modules/libgiognutls.so
#5  0x00007f51f946a445 in _gnutls_io_read_buffered () at /lib64/libgnutls.so.30
#6  0x00007f51f94648ff in _gnutls_recv_in_buffers () at /lib64/libgnutls.so.30
#7  0x00007f51f94661e8 in _gnutls_recv_int () at /lib64/libgnutls.so.30
#8  0x00007f51f94666f4 in gnutls_record_recv () at /lib64/libgnutls.so.30
#9  0x00007f51f977a6fb in g_tls_connection_gnutls_read () at /usr/lib64/gio/modules/libgiognutls.so
#10 0x00007f51f977c901 in g_tls_input_stream_gnutls_read () at /usr/lib64/gio/modules/libgiognutls.so
#11 0x00007f5211503af4 in g_input_stream_read () at /lib64/libgio-2.0.so.0
#12 0x00007f5211503af4 in g_input_stream_read () at /lib64/libgio-2.0.so.0
#13 0x00007f521188569a in soup_filter_input_stream_read_until () at /lib64/libsoup-2.4.so.1
#14 0x00007f5211885843 in soup_filter_input_stream_read_line () at /lib64/libsoup-2.4.so.1
#15 0x00007f521188eff9 in io_read () at /lib64/libsoup-2.4.so.1
#16 0x00007f521188f63d in io_run_until () at /lib64/libsoup-2.4.so.1
#17 0x00007f5211890275 in io_run () at /lib64/libsoup-2.4.so.1
#18 0x00007f521188cbd5 in soup_message_send_request () at /lib64/libsoup-2.4.so.1
#19 0x00007f521189f90e in soup_session_process_queue_item () at /lib64/libsoup-2.4.so.1
#20 0x00007f521189ff1e in soup_session_real_send_message () at /lib64/libsoup-2.4.so.1
#21 0x00007f5211b0f0d5 in rest_proxy_call_sync () at /lib64/librest-0.7.so.0
#22 0x00007f5217739f5a in get_identity_sync () at /lib64/libgoa-backend-1.0.so.1
#23 0x00007f52177398e7 in goa_oauth2_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#24 0x00007f521772c1ba in goa_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#25 0x00007f521772c26d in ensure_credentials_in_thread_func () at /lib64/libgoa-backend-1.0.so.1
#26 0x00007f5211519b81 in run_in_thread () at /lib64/libgio-2.0.so.0
#27 0x00007f5211505ae9 in io_job_thread () at /lib64/libgio-2.0.so.0
#28 0x00007f521152bb10 in g_task_thread_pool_thread () at /lib64/libgio-2.0.so.0
#29 0x00007f5210fb5735 in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#30 0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#31 0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#32 0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7f51faffd700 (LWP 1202)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f52001f8fad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7f51fb7fe700 (LWP 1201)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f5211587f76 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7f5200bff700 (LWP 1199)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f5210f8eba1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7f5217d02ac0 (LWP 1198)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x000055cd38e9c07d in main ()


Thread 6 (Thread 0x7f51fbfff700 (LWP 1300)):
#0  0x00007f52106f9ff9 in syscall () at /lib64/libc.so.6
#1  0x00007f5210fd2dca in g_cond_wait_until () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f63489 in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007f5210fb570a in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 5 (Thread 0x7f51fa7fc700 (LWP 1203)):
#0  0x00007f521069954d in __memcpy_sse2_unaligned () at /lib64/libc.so.6
#1  0x00007f51f8ffec92 in _asn1_str_cpy () at /lib64/libtasn1.so.6
#2  0x00007f51f8fff253 in _asn1_cpy_name () at /lib64/libtasn1.so.6
#3  0x00007f51f90006a3 in _asn1_copy_structure3 () at /lib64/libtasn1.so.6
#4  0x00007f51f8ffd9f9 in _asn1_append_sequence_set () at /lib64/libtasn1.so.6
#5  0x00007f51f8ffcc2e in asn1_der_decoding2 () at /lib64/libtasn1.so.6
#6  0x00007f51f94d7f86 in gnutls_x509_crt_import () at /lib64/libgnutls.so.30
#7  0x00007f51f9775a80 in g_tls_certificate_gnutls_set_property () at /usr/lib64/gio/modules/libgiognutls.so
#8  0x00007f5211267a36 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#9  0x00007f52112695ee in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#10 0x00007f5211502206 in g_initable_new_valist () at /lib64/libgio-2.0.so.0
#11 0x00007f52115022c6 in g_initable_new () at /lib64/libgio-2.0.so.0
#12 0x00007f521152f771 in g_tls_certificate_new_internal () at /lib64/libgio-2.0.so.0
#13 0x00007f521152fa5f in g_tls_certificate_list_new_from_file () at /lib64/libgio-2.0.so.0
#14 0x00007f51f977b1da in g_tls_file_database_gnutls_initable_init () at /usr/lib64/gio/modules/libgiognutls.so
#15 0x00007f5211502217 in g_initable_new_valist () at /lib64/libgio-2.0.so.0
#16 0x00007f52115022c6 in g_initable_new () at /lib64/libgio-2.0.so.0
#17 0x00007f521189eb74 in soup_session_set_property () at /lib64/libsoup-2.4.so.1
#18 0x00007f5211269bbb in g_object_set_valist () at /lib64/libgobject-2.0.so.0
#19 0x00007f521126a37c in g_object_set () at /lib64/libgobject-2.0.so.0
#20 0x00007f5211b0b359 in rest_proxy_init () at /lib64/librest-0.7.so.0
#21 0x00007f52112858c1 in g_type_create_instance () at /lib64/libgobject-2.0.so.0
#22 0x00007f52112676ab in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#23 0x00007f52112695ee in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#24 0x00007f52112698a1 in g_object_new () at /lib64/libgobject-2.0.so.0
#25 0x00007f5217739f20 in get_identity_sync () at /lib64/libgoa-backend-1.0.so.1
#26 0x00007f52177398e7 in goa_oauth2_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#27 0x00007f521772c1ba in goa_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#28 0x00007f521772c26d in ensure_credentials_in_thread_func () at /lib64/libgoa-backend-1.0.so.1
#29 0x00007f5211519b81 in run_in_thread () at /lib64/libgio-2.0.so.0
#30 0x00007f5211505ae9 in io_job_thread () at /lib64/libgio-2.0.so.0
#31 0x00007f521152bb10 in g_task_thread_pool_thread () at /lib64/libgio-2.0.so.0
#32 0x00007f5210fb5735 in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#33 0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#34 0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#35 0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7f51faffd700 (LWP 1202)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f52001f8fad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7f51fb7fe700 (LWP 1201)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f5211587f76 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7f5200bff700 (LWP 1199)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f5210f8eba1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7f5217d02ac0 (LWP 1198)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x000055cd38e9c07d in main ()


Thread 6 (Thread 0x7f51fbfff700 (LWP 1300)):
#0  0x00007f52106f9ff9 in syscall () at /lib64/libc.so.6
#1  0x00007f5210fd2dca in g_cond_wait_until () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f63489 in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007f5210fb570a in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 5 (Thread 0x7f51fa7fc700 (LWP 1203)):
#0  0x00007f521067c46b in _int_malloc () at /lib64/libc.so.6
#1  0x00007f521067eab2 in calloc () at /lib64/libc.so.6
#2  0x00007f51f9000634 in _asn1_copy_structure3 () at /lib64/libtasn1.so.6
#3  0x00007f51f8ffd9f9 in _asn1_append_sequence_set () at /lib64/libtasn1.so.6
#4  0x00007f51f8ffcc2e in asn1_der_decoding2 () at /lib64/libtasn1.so.6
#5  0x00007f51f94d7f86 in gnutls_x509_crt_import () at /lib64/libgnutls.so.30
#6  0x00007f51f94dbe45 in gnutls_x509_crt_list_import () at /lib64/libgnutls.so.30
#7  0x00007f51f94dc177 in gnutls_x509_crt_list_import2 () at /lib64/libgnutls.so.30
#8  0x00007f51f94e30d9 in gnutls_x509_trust_list_add_trust_mem () at /lib64/libgnutls.so.30
#9  0x00007f51f94e34af in gnutls_x509_trust_list_add_trust_file () at /lib64/libgnutls.so.30
#10 0x00007f5211267a36 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#11 0x00007f52112695ee in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007f5211502206 in g_initable_new_valist () at /lib64/libgio-2.0.so.0
#13 0x00007f52115022c6 in g_initable_new () at /lib64/libgio-2.0.so.0
#14 0x00007f521189eb74 in soup_session_set_property () at /lib64/libsoup-2.4.so.1
#15 0x00007f5211269bbb in g_object_set_valist () at /lib64/libgobject-2.0.so.0
#16 0x00007f521126a37c in g_object_set () at /lib64/libgobject-2.0.so.0
#17 0x00007f5211b0b374 in rest_proxy_init () at /lib64/librest-0.7.so.0
#18 0x00007f52112858c1 in g_type_create_instance () at /lib64/libgobject-2.0.so.0
#19 0x00007f52112676ab in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#20 0x00007f52112695ee in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#21 0x00007f52112698a1 in g_object_new () at /lib64/libgobject-2.0.so.0
#22 0x00007f5217739f20 in get_identity_sync () at /lib64/libgoa-backend-1.0.so.1
#23 0x00007f52177398e7 in goa_oauth2_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#24 0x00007f521772c1ba in goa_provider_ensure_credentials_sync () at /lib64/libgoa-backend-1.0.so.1
#25 0x00007f521772c26d in ensure_credentials_in_thread_func () at /lib64/libgoa-backend-1.0.so.1
#26 0x00007f5211519b81 in run_in_thread () at /lib64/libgio-2.0.so.0
#27 0x00007f5211505ae9 in io_job_thread () at /lib64/libgio-2.0.so.0
#28 0x00007f521152bb10 in g_task_thread_pool_thread () at /lib64/libgio-2.0.so.0
#29 0x00007f5210fb5735 in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#30 0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#31 0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#32 0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7f51faffd700 (LWP 1202)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f52001f8fad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7f51fb7fe700 (LWP 1201)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f5211587f76 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7f5200bff700 (LWP 1199)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8eb5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f5210f8eba1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f5210fb4d38 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f52109c65ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f52106ffead in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7f5217d02ac0 (LWP 1198)):
#0  0x00007f52106f432d in poll () at /lib64/libc.so.6
#1  0x00007f5210f8ea46 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f5210f8edd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x000055cd38e9c07d in main ()
Comment 10 Debarshi Ray 2016-08-09 15:59:28 UTC 
Another question. How many online accounts do you have? I am asking because if you have more than a few (for some definition of 'few'), then various applications might be constantly asking goa-daemon to verify the credentials, leading to some constant CPU activity.

Just trying to get a feel for how to reproduce the bug.

Some strace logs would also be helpful:
$ strace -o log-file -p <PID-of-goa-daemon>
Comment 11 Soeren Grunewald 2016-08-10 06:06:41 UTC 
Created attachment 1189468 [details]
goa-daemon strace log

In gnome-control-center online-accounts only the google account shows up. But in empathy I have also an old ICQ account as well as a freenode irc account.

The issue seem to appear every morning when I wake the machine from suspend. But it also happens after a reboot. Maybe it has something to do when the network becomes ready. Because I see it only on my office machine where I have bridged my main interface and dhcp on the bridge.

Anyway, please see the attached strace log. You will notice the EAGAIN...

> futex(0x7f59d000e4e0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
Comment 12 avitygrai 2016-08-10 06:40:27 UTC 
I've left strace running (no -o option) while disabling all of the Settings -> Online Accounts -> "Use for" toggles. I turned the services on one-by-one and strace went bonkers when I enabled the Calendar for my Google account. I had to turn all of the Google services off to get the goa-daemon process back down, then enabled everything but Calendar and it seems to be behaving itself so far. 

I would have attached my gstack and strace output, but I don't see where to attach it (viewing this through a browser at https://bugzilla.redhat.com/show_bug.cgi?id=1346228).
Comment 13 Christophe Fergeau 2016-08-10 06:55:24 UTC 
If you are logged in with a bugzilla account, you should have a "Add an attachment" link near the top. What is interesting is an strace of the goa-daemon process while it's using too much CPU (this bug says it can consistently eat up 15% CPU while being in the background).
Comment 14 avitygrai 2016-08-10 08:51:57 UTC 
Created attachment 1189512 [details]
gstack with goa-daemon running and all accounts/services enabled
Comment 15 avitygrai 2016-08-10 08:59:21 UTC 
Created attachment 1189513 [details]
strace with goa-daemon running and all accounts/services enabled

I was also seeing about 15% usage from goa-daemon with only a virtual terminal window running.
Comment 16 Debarshi Ray 2016-08-10 18:14:03 UTC 
(In reply to avitygrai from comment #12)
> I turned the services on one-by-one
> and strace went bonkers when I enabled the Calendar for my Google account. I
> had to turn all of the Google services off to get the goa-daemon process
> back down, then enabled everything but Calendar and it seems to be behaving
> itself so far.

It is evolution-data-server's calendaring component that reacts to the Calendar switch. It could be calling EnsureCredentials very aggressively against your Google account for some reason.

Milan might know.
Comment 17 Milan Crha 2016-08-11 05:42:24 UTC 
I guess this is [1]. Could I ask for a CalDAV log as described at [2], please? There is no need for a full log, as it's growing quickly, the last 200-500 lines would be fine. Thanks in advance.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=761450
[2] https://bugzilla.gnome.org/show_bug.cgi?id=761450#c1
Comment 18 Dimitris 2016-08-24 04:38:01 UTC 
Hi,

I just experienced this under 3.20.3-1.fc24.

Running the "CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w" command in a terminal, I see a rapid-fire succession of requests like:

> OPTIONS /caldav/v2/<my email address>/events/ HTTP/1.1
> Soup-Debug-Timestamp: 1472012979
> Soup-Debug: SoupSessionSync 1 (0x55ac43da95e0), SoupMessage 18 (0x7f8a240010b0), SoupSocket 18 (0x7f8a30002420)
> Host: apidata.googleusercontent.com
> User-Agent: Evolution/3.20.5
> Connection: close
> Accept-Language: en-us, en;q=0.9
> Authorization: Bearer <access token>

followed by:

< HTTP/1.1 403 Forbidden
< Soup-Debug-Timestamp: 1472012979
< Soup-Debug: SoupMessage 17 (0x7f8a4c0090b0)
< Vary: X-Origin
< Content-Type: text/html; charset=UTF-8
< Date: Wed, 24 Aug 2016 04:29:39 GMT
< Expires: Wed, 24 Aug 2016 04:29:39 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alternate-Protocol: 443:quic
< Alt-Svc: quic=":443"; ma=2592000; v="35,34,33,32,31,30"
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Connection: close
< 
< Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API Console: https://console.developers.google.com/apis/api/caldav/quotas?project=923794261470

It looks like evolution doesn't recognize this as a throttling response and keeps retrying immediately.
Comment 19 Milan Crha 2016-08-24 16:02:13 UTC 
Thanks for the update. It helped a lot. I fixed this upstream at [1]. I'll provide an update with the upstream fix included shortly.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=761450
Comment 20 Dimitris 2016-08-24 16:59:18 UTC 
Thanks!

Do you think this is the root cause? Even if 403 was a "legitimate" response (e.g. I was accessing a calendar I no longer had permission to read), that code path shouldn't result in an immediate retry.

Looking at the patch (and please ignore me if I'm wrong here, I haven't looked at this code before), the return value from status_code_to_result() won't change, and the "side effect" is still to call g_propagate_error().  These two evidently didn't stop the request flood in the existing code.
Comment 21 Fedora Update System 2016-08-24 17:21:35 UTC 
evolution-data-server-3.20.5-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9821d32bad
Comment 22 Fedora Update System 2016-08-25 10:31:37 UTC 
evolution-data-server-3.20.5-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9821d32bad
Comment 23 Milan Crha 2016-08-25 13:23:35 UTC 
(In reply to Dimitris from comment #20)
> Do you think this is the root cause? Even if 403 was a "legitimate" response
> (e.g. I was accessing a calendar I no longer had permission to read), that
> code path shouldn't result in an immediate retry.

The main fix is this change:
+ cbdav->priv->using_bearer_auth = TRUE;
the error itself is just an extra addition, a bonus. The thing is that the code behaves differently when a password-based login is used and when a password-less login is used. The recognition failed due to using password-less, but not having is marked in the structure (the using_bearer_auth was FALSE, which made the code think that it's actually asking the user for the password, which was not true).
Comment 24 Fedora Update System 2016-08-26 10:20:36 UTC 
evolution-data-server-3.20.5-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
Comment 25 Dimitris 2016-08-29 06:50:49 UTC 
Still seeing this here.  Seems to correlate with
- Machine connects to one network.
- Suspend.
- Resume in another location
- Machine connects to another network
- After a while:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                   
 2126 d         20   0 1148204 131448  27624 S  37.9  0.8   8:17.90 goa-daemon

attaching pstack output
Comment 26 Dimitris 2016-08-29 06:51:42 UTC 
Hmm can't attach, inline:

Thread 7 (Thread 0x7f55b11ee700 (LWP 14605)):
#0  0x00007f55c36a00b9 in syscall () from /lib64/libc.so.6
#1  0x00007f55c3f78c8a in g_cond_wait_until () from /lib64/libglib-2.0.so.0
#2  0x00007f55c3f09469 in g_async_queue_pop_intern_unlocked () from /lib64/libglib-2.0.so.0
#3  0x00007f55c3f5b6c6 in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0
#4  0x00007f55c3f5acf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f55c396c5ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f55c36a5f6d in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7f559a16d700 (LWP 10472)):
#0  0x00007f55c369a3ed in poll () from /lib64/libc.so.6
#1  0x00007f55c44c2905 in g_socket_condition_timed_wait () from /lib64/libgio-2.0.so.0
#2  0x00007f55c44c382a in g_socket_receive_with_timeout () from /lib64/libgio-2.0.so.0
#3  0x00007f55c44a9a31 in g_input_stream_read () from /lib64/libgio-2.0.so.0
#4  0x00007f55b016ab45 in g_tls_connection_gnutls_pull_func () from /usr/lib64/gio/modules/libgiognutls.so
#5  0x00007f559bcfc445 in _gnutls_io_read_buffered () from /lib64/libgnutls.so.30
#6  0x00007f559bcf68ff in _gnutls_recv_in_buffers () from /lib64/libgnutls.so.30
#7  0x00007f559bcf81e8 in _gnutls_recv_int () from /lib64/libgnutls.so.30
#8  0x00007f559bcf86f4 in gnutls_record_recv () from /lib64/libgnutls.so.30
#9  0x00007f55b016c6fb in g_tls_connection_gnutls_read () from /usr/lib64/gio/modules/libgiognutls.so
#10 0x00007f55b016e901 in g_tls_input_stream_gnutls_read () from /usr/lib64/gio/modules/libgiognutls.so
#11 0x00007f55c44a9a31 in g_input_stream_read () from /lib64/libgio-2.0.so.0
#12 0x00007f55c44a9a31 in g_input_stream_read () from /lib64/libgio-2.0.so.0
#13 0x00007f55c482b69a in soup_filter_input_stream_read_until (fstream=0x7f55a0884430, buffer=0x7f559003acb0, length=length@entry=8192, boundary=boundary@entry=0x7f55c485f24a, boundary_length=boundary_length@entry=1, blocking=blocking@entry=1, include_boundary=1, got_boundary=0x7f559a16c740, cancellable=0x55f9371d3790, error=0x7f559a16c7d0) at soup-filter-input-stream.c:226
#14 0x00007f55c482b843 in soup_filter_input_stream_read_line (fstream=<optimized out>, buffer=<optimized out>, length=length@entry=8192, blocking=blocking@entry=1, got_line=got_line@entry=0x7f559a16c740, cancellable=cancellable@entry=0x55f9371d3790, error=0x7f559a16c7d0) at soup-filter-input-stream.c:186
#15 0x00007f55c4834ff9 in read_headers (error=0x7f559a16c7d0, cancellable=0x55f9371d3790, blocking=1, msg=0x7f55906f4ca0) at soup-message-io.c:224
#16 io_read (msg=msg@entry=0x7f55906f4ca0, blocking=blocking@entry=1, cancellable=cancellable@entry=0x55f9371d3790, error=error@entry=0x7f559a16c7d0) at soup-message-io.c:616
#17 0x00007f55c483563d in io_run_until (msg=msg@entry=0x7f55906f4ca0, blocking=blocking@entry=1, read_state=read_state@entry=SOUP_MESSAGE_IO_STATE_DONE, write_state=write_state@entry=SOUP_MESSAGE_IO_STATE_DONE, cancellable=cancellable@entry=0x55f9371d3790, error=error@entry=0x7f559a16c820) at soup-message-io.c:982
#18 0x00007f55c4836275 in io_run (msg=0x7f55906f4ca0, blocking=1) at soup-message-io.c:1053
#19 0x00007f55c4836473 in soup_message_io_client (item=item@entry=0x7f55a11b19b0, iostream=<optimized out>, async_context=async_context@entry=0x0, get_headers_cb=get_headers_cb@entry=0x7f55c4832820 <get_request_headers>, parse_headers_cb=parse_headers_cb@entry=0x7f55c48325b0 <parse_response_headers>, header_data=header_data@entry=0x7f55a11b19b0, completion_cb=0x7f55c4845f30 <message_completed>, completion_data=0x7f55a11b19b0) at soup-message-io.c:1233
#20 0x00007f55c4832bd5 in soup_message_send_request (item=0x7f55a11b19b0, completion_cb=0x7f55c4845f30 <message_completed>, user_data=0x7f55a11b19b0) at soup-message-client-io.c:161
#21 0x00007f55c484590e in soup_session_process_queue_item (session=<optimized out>, item=0x7f55a11b19b0, should_cleanup=<optimized out>, loop=<optimized out>) at soup-session.c:2019
#22 0x00007f55c4845f1e in soup_session_real_send_message (session=0x7f5590d084e0, msg=0x7f55906f4ca0) at soup-session.c:2246
#23 0x00007f55c4ab50d5 in rest_proxy_call_sync (call=0x7f55a11857a0, error_out=0x7f559a16cad0) at rest-proxy-call.c:1465
#24 0x00007f55ca6e4f5a in get_identity_sync () from /lib64/libgoa-backend-1.0.so.1
#25 0x00007f55ca6e48e7 in goa_oauth2_provider_ensure_credentials_sync () from /lib64/libgoa-backend-1.0.so.1
#26 0x00007f55ca6d71ba in goa_provider_ensure_credentials_sync () from /lib64/libgoa-backend-1.0.so.1
#27 0x00007f55ca6d726d in ensure_credentials_in_thread_func () from /lib64/libgoa-backend-1.0.so.1
#28 0x00007f55c44bfa4f in run_in_thread () from /lib64/libgio-2.0.so.0
#29 0x00007f55c44aba06 in io_job_thread () from /lib64/libgio-2.0.so.0
#30 0x00007f55c44d19bd in g_task_thread_pool_thread () from /lib64/libgio-2.0.so.0
#31 0x00007f55c3f5b6ee in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0
#32 0x00007f55c3f5acf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#33 0x00007f55c396c5ca in start_thread () from /lib64/libpthread.so.0
#34 0x00007f55c36a5f6d in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f55b19ef700 (LWP 2142)):
#0  0x00007f55c369a3ed in poll () from /lib64/libc.so.6
#1  0x00007f55c3f34a06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f55c3f34b1c in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#3  0x00007f55b19f6fad in dconf_gdbus_worker_thread () from /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f55c3f5acf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f55c396c5ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f55c36a5f6d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f55b23fd700 (LWP 2140)):
#0  0x00007f55c369a3ed in poll () from /lib64/libc.so.6
#1  0x00007f55c3f34a06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f55c3f34d92 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x00007f55c452de46 in gdbus_shared_thread_func () from /lib64/libgio-2.0.so.0
#4  0x00007f55c3f5acf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f55c396c5ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f55c36a5f6d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f55b33ff700 (LWP 2138)):
#0  0x00007f55c369a3ed in poll () from /lib64/libc.so.6
#1  0x00007f55c3f34a06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f55c3f34b1c in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#3  0x00007f55c3f34b61 in glib_worker_main () from /lib64/libglib-2.0.so.0
#4  0x00007f55c3f5acf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f55c396c5ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f55c36a5f6d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f55b3f71700 (LWP 2137)):
#0  0x00007f55c3971bd0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f55bdd7ea3c in __gthread_cond_wait (__mutex=<optimized out>, __cond=<optimized out>) at /usr/src/debug/gcc-6.1.1-20160621/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/x86_64-redhat-linux/bits/gthr-default.h:864
#2  std::condition_variable::wait (this=<optimized out>, __lock=...) at ../../../../../libstdc++-v3/src/c++11/condition_variable.cc:53
#3  0x00007f55c8040296 in bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadRunLoop() () from /lib64/libjavascriptcoregtk-4.0.so.18
#4  0x00007f55c80403c9 in bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadEntryPoint(bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>*) () from /lib64/libjavascriptcoregtk-4.0.so.18
#5  0x00007f55bdd84aaf in std::execute_native_thread_routine (__p=0x55f937190370) at ../../../../../libstdc++-v3/src/c++11/thread.cc:83
#6  0x00007f55c396c5ca in start_thread () from /lib64/libpthread.so.0
#7  0x00007f55c36a5f6d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f55cacb8ac0 (LWP 2126)):
#0  0x00007f55c369a3ed in poll () from /lib64/libc.so.6
#1  0x00007f55c3f34a06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f55c3f34d92 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x000055f936ad807d in main ()
Comment 27 Dimitris 2016-08-29 06:56:17 UTC 
Then, right after when I run:
CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w
g-o-a consistently and immediately stops spinning.  Output from this is several of:

> OPTIONS /caldav/v2/<... id ...>/events/ HTTP/1.1
> Soup-Debug-Timestamp: 1472453551
> Soup-Debug: SoupSessionSync 1 (0x55eaff96b4d0), SoupMessage 1 (0x7f14200620b0), SoupSocket 1 (0x7f1420007430)
> Host: apidata.googleusercontent.com
> User-Agent: Evolution/3.20.5
> Connection: close
> Accept-Language: en-us, en;q=0.9
> Authorization: Bearer <token>

< HTTP/1.1 403 Forbidden
< Soup-Debug-Timestamp: 1472453551
< Soup-Debug: SoupMessage 1 (0x7f14200620b0)
< Vary: X-Origin
< Content-Type: text/html; charset=UTF-8
< Date: Mon, 29 Aug 2016 06:52:31 GMT
< Expires: Mon, 29 Aug 2016 06:52:31 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alternate-Protocol: 443:quic
< Alt-Svc: quic=":443"; ma=2592000; v="35,34,33,32,31,30"
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Connection: close
< 
< Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API Console: https://console.developers.google.com/apis/api/caldav/quotas?project=923794261470

only this time, running this command doesn't loop forever, and gets g-o-a to quiet down.
Comment 28 Milan Crha 2016-08-29 12:35:08 UTC 
Could it be that the old evolution-calendar-factory-subprocess was talking to the GOA, and when you run it with the CALDAV_DEBUG=all, then it fixed itself, because of running the updated version of it? I cannot explain otherwise why this would happen, unless it's something else talking to GOA, which I doubt of.
Comment 29 Milan Crha 2016-09-07 15:10:23 UTC 
Just a note that I made one follow up change upstream, which will be part of 3.21.92 and beyond:
https://bugzilla.gnome.org/show_bug.cgi?id=761450#c15
Comment 30 Milan Crha 2016-09-12 16:32:46 UTC 
(In reply to Milan Crha from comment #29)
> Just a note that I made one follow up change upstream, which will be part of
> 3.21.92 and beyond:
> https://bugzilla.gnome.org/show_bug.cgi?id=761450#c15

The change is currently building as a test build for Fedora 24 here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=15603445

I'll wait a bit for it for testing, then I'll provide it as a regular update.
Comment 31 Debarshi Ray 2016-09-13 11:17:29 UTC 
*** Bug 1375058 has been marked as a duplicate of this bug. ***
Comment 32 Fedora Update System 2016-09-14 18:01:04 UTC 
evolution-data-server-3.20.5-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6438ef15f2
Comment 33 Fedora Update System 2016-09-16 00:54:10 UTC 
evolution-data-server-3.20.5-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6438ef15f2
Comment 34 Fedora Update System 2016-09-19 03:19:04 UTC 
evolution-data-server-3.20.5-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
Comment 35 Fedora Update System 2016-10-11 03:22:36 UTC 
evolution-data-server-3.20.5-5.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2c3c63bada
Comment 36 Fedora Update System 2016-10-13 21:53:42 UTC 
evolution-data-server-3.20.5-5.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
Comment 37 Artur Flinta 2016-10-18 22:54:10 UTC 
Since last upgrade of evolution-data-server to 3.20.5-5.fc24 I've started encountering similar problem on all my google calendars in Evolution:

Failed to login to the server: Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API Console: https://console.developers.google.com/apis/api/caldav/quotas?project=.....

This problem persists few days so I'm started to wonder if everything is OK with EDS.

I don't remember working version of EDS, but I do dnf upgrade every few days, so change in versions shouldn't be big.
Comment 38 Milan Crha 2016-10-19 14:08:20 UTC 
I'm afraid that the problem was there all the time, the only difference is that the previous versions of the evolution-data-server silently hid the error and the user didn't know. He/she could sometimes notice extensive CPU usage caused by this error returned by the server. By the way, do you use GNOME Online Accounts or you enter your Google accounts directly in the evolution?
Comment 39 Artur Flinta 2016-10-19 19:50:10 UTC 
I'm using GNOME Online Accounts. Should I try add them directly using dedicated password?
Comment 40 Milan Crha 2016-10-20 07:23:04 UTC 
(In reply to Artur Flinta from comment #39)
> I'm using GNOME Online Accounts. Should I try add them directly using
> dedicated password?

Nope, I want both options working, thus do not change your settings please. By the way, the internal evolution-data-server google auth doesn't require any specific password since 3.20.x, if it's compiled with the google auth on (Fedora does have it turned on).
Comment 41 Artur Flinta 2016-10-20 07:42:18 UTC 
Good to know, it was some time ago when I preferred internal evolution account instead of GNOME Online Accounts (the latter was unreliable).
Comment 42 Artur Flinta 2016-10-24 20:45:08 UTC 
OK, I've disabled in GNOME Online Accounts my gmail account, and added calendar, address book and tasks from google directly in evolution and... no errors anymore :) So maybe there is something wrong with GOA?
Comment 43 Milan Crha 2016-10-25 06:37:02 UTC 
I tried to explain how I understand the issue here:
https://mail.gnome.org/archives/evolution-list/2016-October/msg00124.html
Comment 44 Artur Flinta 2016-10-25 10:25:50 UTC 
Thanks!
Note You need to log in before you can comment on or make changes to this bug.