Bug 1382498 - goa-daemon (still) using lots of CPU time
Summary: goa-daemon (still) using lots of CPU time
Keywords:
Status: CLOSED DUPLICATE of bug 1375058
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-10-06 20:05 UTC by Mikkel Lauritsen
Modified: 2016-10-07 08:29 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-10-07 08:29:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mikkel Lauritsen 2016-10-06 20:05:37 UTC
This might be a duplicate of #1346228 and/or #1375058.

With everything updated to the latest releases and in particular evolution-data-server-3.20.5-4.fc24.x86_64 I'm still seeing goa-daemon using 15-30% CPU time.

It seems to be related to the connectivity to an Exchange server - when the VPN connection that makes the server visible is inactive goa-daemon uses a lot of CPU; starting the VPN connection makes goa-daemon drop to 0% in top.

gstack output:

Thread 7 (Thread 0x7f74c5df5700 (LWP 10824)):
#0  0x00007f74ecdf80b9 in syscall () from /lib64/libc.so.6
#1  0x00007f74ed6d0c8a in g_cond_wait_until () from /lib64/libglib-2.0.so.0
#2  0x00007f74ed661469 in g_async_queue_pop_intern_unlocked () from /lib64/libglib-2.0.so.0
#3  0x00007f74ed6b36c6 in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0
#4  0x00007f74ed6b2cf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f74ed0c45ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f74ecdfdf6d in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7f74d7fff700 (LWP 10242)):
#0  0x00007f74ecdf80b9 in syscall () from /lib64/libc.so.6
#1  0x00007f74ed6d0c8a in g_cond_wait_until () from /lib64/libglib-2.0.so.0
#2  0x00007f74ed661469 in g_async_queue_pop_intern_unlocked () from /lib64/libglib-2.0.so.0
#3  0x00007f74ed6b36c6 in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0
#4  0x00007f74ed6b2cf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f74ed0c45ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f74ecdfdf6d in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f74d677e700 (LWP 1486)):
#0  0x00007f74ecdf23ed in poll () from /lib64/libc.so.6
#1  0x00007f74ed68ca06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f74ed68cb1c in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#3  0x00007f74d6785fad in dconf_gdbus_worker_thread () from /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f74ed6b2cf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f74ed0c45ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f74ecdfdf6d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f74d77fe700 (LWP 1484)):
#0  0x00007f74ecdf23ed in poll () from /lib64/libc.so.6
#1  0x00007f74ed68ca06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f74ed68cd92 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x00007f74edc85e46 in gdbus_shared_thread_func () from /lib64/libgio-2.0.so.0
#4  0x00007f74ed6b2cf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f74ed0c45ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f74ecdfdf6d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f74dcbff700 (LWP 1482)):
#0  0x00007f74ecdf23ed in poll () from /lib64/libc.so.6
#1  0x00007f74ed68ca06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f74ed68cb1c in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#3  0x00007f74ed68cb61 in glib_worker_main () from /lib64/libglib-2.0.so.0
#4  0x00007f74ed6b2cf5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007f74ed0c45ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f74ecdfdf6d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f74dd6c8700 (LWP 1481)):
#0  0x00007f74ed0c9bd0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f74e74d62fc in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib64/libstdc++.so.6
#2  0x00007f74f17982b6 in bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadRunLoop() () from /lib64/libjavascriptcoregtk-4.0.so.18
#3  0x00007f74f17983e9 in bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadEntryPoint(bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>*) () from /lib64/libjavascriptcoregtk-4.0.so.18
#4  0x00007f74e74dc36f in ?? () from /lib64/libstdc++.so.6
#5  0x00007f74ed0c45ca in start_thread () from /lib64/libpthread.so.0
#6  0x00007f74ecdfdf6d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f74f440eac0 (LWP 1464)):
#0  0x00007f74ecdf23ed in poll () from /lib64/libc.so.6
#1  0x00007f74ed68ca06 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007f74ed68cd92 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x00005595e23ca07d in main ()

Comment 1 Milan Crha 2016-10-07 08:28:11 UTC
Thanks for a bug report. This is bug #1375058 from my point of view, thus I'm closing this as such. As your steps are slightly different, I might be useful to see what it does for you in the background, thus please follow the steps from  bug #1375058 comment #10, where Dimitris claimed his result in bug #1375058 comment #12. Thanks in advance.

Comment 2 Milan Crha 2016-10-07 08:29:39 UTC

*** This bug has been marked as a duplicate of bug 1375058 ***


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