GNOME Bugzilla – Bug 756170
Unable to load evolution with network active
Last modified: 2015-10-09 05:53:33 UTC
Created attachment 312790 [details] Screenshot I have several Google Apps accounts linked up to Evolution. When I start evolution it sits there trying to load each inbox for about 20 minutes before failing. I then need to restart Evolution several times before it loads properly. This bug has existed for a couple of years now across multiple machines I own. The one workaround to get it to work is to disable networking, load Evolution, then start networking again. What can I provide to debug this issue?
Thanks for a bug report. Could you install debuginfo packages for the evolution-data-server and evolution, then get a backtrace of the evolution in this state, to see what it does, please? You can get the backtrace with command like this: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt 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). It can be that the GTask thread pool got out of threads, but some are waiting for other threads, which are in the queue, thus this simply starves. Could you also provide exact versions of the evolution packages you've installed together with glib/glib2 packages, please?
Created attachment 312918 [details] backtrace
Thanks Milan. it appears to be something DNS lookup related (looking at the backtrace). I seem to vaguely remember there were errors related to this at some point before (FC16 maybe?), where some threads got the right lookup, and others just sat idle. glibc-2.22-3.fc23.x86_64 glib2-2.46.0-1.fc23.i686 evolution-data-server-3.18.0-1.fc23.x86_64 evolution-3.18.0-1.fc23.x86_64 If it's DNS related, things worth mentioning. All the accounts use the same hosts. I have up to 22 separate accounts active that would be doing the same lookup. I'm using 8.8.8.8 and 8.8.4.4 as resolvers.
Thanks for the update. According to the backtrace, there are many (20) g_task_thread_pool_thread threads, and a significant part of them (14) are waiting in g_task_run_in_thread_sync(), which means they need to run another GTask thread. So this is starving the requests. There is no good way to pile same address requests checking in general. I can add such enhancement in the evolution, which will cover threads with camel_network_service_can_reach_sync(), there are 11 of them in your backtrace, but it'll not help much, because of g_libproxy_resolver_lookup() asking the GTask to create another thread. I'm moving this to glib (it feels better to have the address enumeration queue there too, thus anyone can benefit from it), and I'm reopening bug #687223, which claims to be fixed in your version. *** This bug has been marked as a duplicate of bug 687223 ***