Created attachment 887208 [details] backtrace Description of problem: The VPN disconnects after 24hrs and then when I reconnect the VPN evolution goes nuts turning on the fans on my laptop. It doesn't seem to recover. Version-Release number of selected component (if applicable): evolution-3.10.4-2.fc20.x86_64 evolution-debuginfo-3.10.4-2.fc20.x86_64 evolution-data-server-3.10.4-3.fc20.x86_64 evolution-data-server-debuginfo-3.10.4-3.fc20.x86_64 evolution-help-3.10.4-2.fc20.noarch evolution-ews-3.10.4-1.fc20.x86_64 How reproducible: Seems to be everyday Steps to Reproduce: 1. start the vpn 2. start evolution with an account only accessible through the vpn 3. wait for the vpn to die 4. reconnect the vpn Actual results: evolution goes nuts with loads of threads at the bottom Expected results: it simply reconnects to the accounts that it couldn't access Additional info:
I suspect that this might be a duplicate of some other bug but I can't find it.
Thanks for a bug report. Support for per-account online detection (using GNetworkMonitor in the background) had been added for 3.12.0+ only. Yours 3.10.4 doesn't manage vpn changes well. There had been done also some minor changes for 3.12.1+ too. I see in the backtrace that couple threads are resolving a network address, while the main thread is in the paint operation. That paint might be due to a GtkSpinner in the status bar, redrawing the animation of the spinning circles. I mean, the main issue with high CPU usage might be part of the animation drawing in the status bar. The other part of the problem is that the address resolution takes unreasonably long to stop. As I mentioned in the beginning, evolution 3.12.1 (and evolution-data-server of the same version) is supposed to address the vpn changes gracefully.