Bug 1088985

Summary: evolution doesn't handle vpn disconnecting and reconnecting
Product: [Fedora] Fedora Reporter: Ben Woodard <woodard>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: fabiano, lucilanga, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: evolution-3.12.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-22 07:32:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace none

Description Ben Woodard 2014-04-17 14:59:41 UTC
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:

Comment 1 Ben Woodard 2014-04-17 15:00:51 UTC
I suspect that this might be a duplicate of some other bug but I can't find it.

Comment 2 Milan Crha 2014-04-22 07:32:49 UTC
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.