Created attachment 874637 [details] gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txtresults from: Description of problem: After resuming evolution consumes 100% on all my system's processors Version-Release number of selected component (if applicable): evolution-3.10.4-2.fc20.x86_64 How reproducible: Frequently but not necessarily always Steps to Reproduce: 1. configure a mail account that can only be reached through a vpn 2. bring up the VPN & make sure that you have a connection to that email account by reading email 3. suspend the laptop 4. resume the laptop 5. reconnect the VPN 6. wait a while and you will note their are many spinning evolution processes and the laptop is heating up. Actual results: The fans on the laptop kick on, the power utilization goes way up and evolution is practically unresponsive Expected results: evolution quickly discovers that its previous connection has quit and then reconnects to the imap server. Additional info:
This also seems to happen sometimes in the morning after the vpn has gone down and then I reconnect. Eventually it recovers but it can use a considerable amount of battery for those several minutes until things stabilize and also evolution is almost unusuable during that time.
Thanks for a bug report. From what I see, multiple/many threads are checking whether certain addresses are available (getaddrinfo), while the main thread is stuck at a resort of a GTask queue, which is probably taking the most of CPU. From that I'd say that the problem is (partly) caused by GLib and its GTask implementation. Of course, it can be also caused be the way how evolution uses it, in connection with GNetworkMonitor. Any hints what to do when checking multiple addresses (say 10+) to not cause this GLib's behaviour will be appreciated. By the way, how many mail accounts do you have configured in evolution? Thread 1 (Thread 0x7f4bc1460a40 (LWP 2712)): #0 0x0000003ed6036c6c in g_cancellable_is_cancelled (cancellable=0x5dc3d70) at gcancellable.c:292 #1 0x0000003ed607c07c in g_task_compare_priority (a=0x5df3800, b=0x6ebc060, user_data=<optimized out>) at gtask.c:1791 #2 0x00000034bba1f01d in g_async_queue_invert_compare (v1=<optimized out>, v2=<optimized out>, sd=<optimized out>) at gasyncqueue.c:359 #3 0x00000034bba45119 in g_list_sort_merge (user_data=0x7fff847fdbc0, compare_func=0x34bba1f010 <g_async_queue_invert_compare>, l2=0x6ebaee0, l1=0x6eb2f80) at glist.c:1066 #4 g_list_sort_real (list=list@entry=0x5e16840, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at glist.c:1112 #5 0x00000034bba450cd in g_list_sort_real (list=list@entry=0x5e16840, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at glist.c:1112 #6 0x00000034bba450cd in g_list_sort_real (list=0x5e16840, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at glist.c:1112 #7 0x00000034bba450bc in g_list_sort_real (list=list@entry=0x6f8ac40, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at glist.c:1112 #8 0x00000034bba450cd in g_list_sort_real (list=0x6f8ac40, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at glist.c:1112 #9 0x00000034bba450bc in g_list_sort_real (list=0x61e23a0, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at glist.c:1112 #10 0x00000034bba45c25 in g_list_sort_with_data (list=<optimized out>, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at glist.c:1183 #11 0x00000034bba59616 in g_queue_sort (queue=0x4bcd708, compare_func=compare_func@entry=0x34bba1f010 <g_async_queue_invert_compare>, user_data=user_data@entry=0x7fff847fdbc0) at gqueue.c:329 #12 0x00000034bba1f8da in g_async_queue_sort_unlocked (queue=<optimized out>, func=func@entry=0x3ed607bff0 <g_task_compare_priority>, user_data=user_data@entry=0x0) at gasyncqueue.c:787 #13 0x00000034bba6fcc5 in g_thread_pool_set_sort_function (pool=0x4bc58b0, func=func@entry=0x3ed607bff0 <g_task_compare_priority>, user_data=user_data@entry=0x0) at gthreadpool.c:949 #14 0x0000003ed607c8b2 in g_task_thread_pool_resort () at gtask.c:1816 #15 task_thread_cancelled (cancellable=<optimized out>, user_data=0x6b92db0) at gtask.c:1259 #16 0x00000034bca104c7 in _g_closure_invoke_va (closure=closure@entry=0x721fd40, return_value=return_value@entry=0x0, instance=instance@entry=0x5ff2ae0, args=args@entry=0x7fff847fde00, n_params=0, param_types=0x0) at gclosure.c:840 #17 0x00000034bca29749 in g_signal_emit_valist (instance=0x5ff2ae0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fff847fde00) at gsignal.c:3238 #18 0x00000034bca2a3af in g_signal_emit (instance=instance@entry=0x5ff2ae0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3386 #19 0x0000003ed6036f65 in g_cancellable_cancel (cancellable=0x5ff2ae0) at gcancellable.c:503 #20 0x000000384f48ce4b in network_service_update_host_reachable_idle_cb (user_data=<optimized out>) at camel-network-service.c:151 #21 0x00000034bba492a6 in g_main_dispatch (context=0x1e48190) at gmain.c:3066 #22 g_main_context_dispatch (context=context@entry=0x1e48190) at gmain.c:3642 #23 0x00000034bba49628 in g_main_context_iterate (context=0x1e48190, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #24 0x00000034bba49a3a in g_main_loop_run (loop=0x4bf90c0) at gmain.c:3907 #25 0x000000384c9aa355 in gtk_main () at gtkmain.c:1158 #26 0x000000000040377f in main (argc=1, argv=0x7fff847fe1f8) at main.c:683
I only have 2 email accts configured RH & gmail.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.