Created attachment 948325 [details] Created via: CAMEL_DEBUG=all evolution >& evo_debug.log Description of problem: Evolution 3.12.7-1 crashes on launch. Version-Release number of selected component (if applicable): 3.12.7-1 How reproducible: Always. Steps to Reproduce: 1. Launch Evolution 2. Click on "X" icon to close it. Actual results: Evolution does not close. Does not respond to mouse clicks or keyboard. "Saving user interface state..." displays along bottom status panel. Process needs to be killed. Expected results: Evolution closes. Additional info: Fedora 21 Workstation, Gnome 3.14.1, updated, Lenovo M93P ThinkCentre, Haswell video
Thanks for a bug report. I'm confused, you said the evolution crashed, but then you cannot close it, so is this about a crash or about a "not closing evolution"? The attached log also doesn't show any crash, and even nothing unusual. There is shown a successful login to your GMail account and no crash. Evolution doesn't close when there are any pending jobs, which are usually shown in the status bar, like the "Saving user interface state" one. This can get starve when there are any background operations, like a check whether a certain server is reachable. You might see such attempts when getting backtrace of running evolution in this state with a gdb 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). You certainly has access to a GMail server, but is it possible your other accounts, even disabled, has trouble to access the configured server address from the network you are currently logged in?
Created attachment 948525 [details] bt.txt
Thanks. I've attached bt.txt generated per your suggestion after launching Evolution and immediately trying to close it. Only the Google account exists, created via Gnome's Online Accounts tool when it ran automatically during after the first post-install boot. I've tried to verify that account's settings but the expected entries in Preferences are not there. Instead, there is a notice the account was created by Online Accounts. The display shows mail from Google is retrieved -- the correct folders are listed and there's a mail count displayed -- but clicking "Inbox" does not result in the display or listing of mail. I.e., the two panels on the right remain empty. The "Saving user interface state" message appears immediately on launch. Some other interactions with the GUI do work. Sporadically, if I click on that account name in Preferences, to select and highlight it before clicking "Modify", it is not highlighted, and the entire GUI stops responding. When I am able to "Modify" account settings, when I click "Close" on that Preferences window, the Windows fades out, the cursor becomes a beachball, and I need to kill Evolution. At every launch, including the initial launch, whether I interact with Evolution or try to close it immediately, when I do try to close... nothing. I've left it alone for several minutes with no change.
I'm adding bt1.txt, created after the Account Editor window refused to close, per above.
Created attachment 948531 [details] bt1.txt
Thanks for the update. Both backtraces are pretty much the same, they show evolution idle, waiting for a response on a server address resolution, concretely 10 times. As there are not installed debuginfo for glibc I cannot tell which servers it tries to reach. These server lookups block all other operations, including the "Saving user interface". Could you install debuginfo for glibc and re-get the backtrace, please? You can install it with this command: $ yum install glibc-debuginfo --enablerepo=updates-debuginfo only make sure that the instlaled glibc package version will match the package version of the debuginfo. If not, then also run: $ yum update glibc In any case, this all shows into some misconfiguration of the network. If it tries to reach the server on some stale connection, or even with IPv6, then it can partly explain the issue. I thought of using GIO_USE_NETWORK_MONITOR environment variable to change the way how GLib check for network availability, but it doesn't seem to work in a way which would be useful for us (the possible values are "base" and "netlink" (quotes for clarity only). It would be only a workaround.
Created attachment 949349 [details] bt3.txt Sorry for the delay. I've reinstalled and updated Workstation. This time, I skipped setting up the Google account via Online Accounts during Gnome's first-boot offering and created the account manually in Evolution. No change in behavior, though. Yum complained it couldn't find an "updates-debuginfo" repo so I added the matching glibc-debuginfo and glibc-debuginfo-common from koji. The attached bt3.txt was then generated after launching Evolution and attempting to close it. When Evolution launched, Gnome popped up a "mail received" message, but I can't verify that. The Gmail account is the only account I've created.
Thanks for the update. All the getaddrinfo calls are resolving "smtp.gmail.com", probably unsuccessfully. There are similar upstream claims filled too, but I doubt this is directly evolution-related, probably some glitch in an underlying library.
I tried to reproduce this with up-to-date fedora 21 and even rawhide, where I added a GMail account in GNOME Online Accounts, run evolution, checked calendar, closed evolution restarted the machine and repeated the evolution checks again, but I didn't get any such behaviour somehow. I'm afraid there is some specific circumstance, which triggers this misbehaviour. Maybe you face something similar to bug #1151665.
Ah, well. Thanks much for looking at this. I did set up a freebie Fastmail account which Evolution handles just fine.
May I close this then?
Please.
Okay, thanks. I will close this, but in a favour of an upstream bug [1]. It's because I just noticed what could cause this, the code currently doesn't do anything smart, it tries connectivity to the servers on each single connection change, while the connection changes can be done multiple in a row, which causes the flood. The [1] was created from bug #1030579, thus I'm marking this under it. [1] https://bugzilla.gnome.org/show_bug.cgi?id=712392 *** This bug has been marked as a duplicate of bug 1030579 ***