GNOME Bugzilla – Bug 787438
Evolution 3.24.5 gets stuck at "Saving User Interface state" on startup
Last modified: 2017-10-02 07:21:30 UTC
>Problem: Evolution often freezes at "Saving user interface state..." at startup, and new email messages do not appear until 'saving user inter....' message has been taken care of either by 1) cancelling it (and waiting for a few minutes) or 2) killing the application (with hope that this message does not pop-up on restart). Canceling takes anything between 1 minute to forever which sometimes necessitates killing evo. >Screenshot: https://i.imgur.com/4HMc9YC.png >Versions: evolution 3.24.5-1 evolution-data-server 3.24.5-1 evolution-spamassassin 3.24.5-1 Arch linux (stable branch) on IPv4 >Further: Maybe similar to bug #727387 reported for evo 3.10x on IPv6 during 2014 and #692302, #706716 during 2013 (all not fixed/accepted). Please let me know how to provide further information. Thank you.
Thanks for a bug report. How many mail accounts do you have configured, please? It can be glib's GTask thread pool gets starving due to ongoing operations. There is not much evolution can do about it, because the problem is in glib, that's why they are not fixed on the evolution side. That is kind of known issue of the GTask interface, which can be seen in bug #774448. To verify you face the same issue, install debuginfo package for evolution-data-server and glib (I do not know how that is packaged in Arch Linux, some distributions have in packages as glib2). Then run evolution and when it'll be in that stuck state, capture backtrace of it, 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).
Thank you for your time and explanation. As mentioned in bug #774448 only happens if there are emails to be synced. Since 2 days I have only received three emails hence problem did not repeat so I will probably wait a few more days to update on backtrace, however, below is info on other questions: > Number of accounts Five (4 Gmail, 1 from 1and1) - all on IMAP protocol. > Arch specific package glib2
(In reply to pingo from comment #2) > As mentioned in bug #774448 only happens if there are emails to be synced. It happens to me also right after start from time to time. I've enabled 7 IMAP and one POP3 account and many disabled. > I will probably wait a few more days to update on backtrace Thanks, it'll show where the problem is, and eventually can prove I'm right or wrong.
Created attachment 359822 [details] evolution backtrace during stuck/saving user interface
Added attachment bt.txt. Also, I tried below as mentioned in Arch wiki (it kind of work). >Quote Failing to Synchronize with Server If you change internet connections, such as switching VPN or restart X, Evolution may have problems connecting to the mail servers. You would see it endlessly trying to connect in the status bar at the bottom. A possible solution is to switch to "Work Offline" select "Don't Synchronize” in the pop-up. Then after a minute has passed, go back to On-line mode. It should now have no problem fetching from the mail servers. https://wiki.archlinux.org/index.php/GNOME/Evolution#Failing_to_Synchronize_with_Server
Thanks for the update. I see you forgot to install any debuginfo package I named at comment #1, or how that's done on the Arch Linux, thus the backtrace is not that useful as it can be. There are quite many threads mentioning /usr/lib/evolution/plugins/liborg-gnome-templates.so which are waiting for an account to be connected. Then there are more threads trying to connect some account. Having those debug symbols available I know it for sure, but I guess you face bug #774448. We can verify it by changing one line in a glib sources and recompile it, but I do now know whether it's easily doable in the Arch Linux (I do not use it myself).
Hello and sorry for delay in response. I had to do something (and understanding) how this works in Arch Linux. As I understand, the binaries we get are stripped of debut symbols therefore to get meaningful debug, package(s) in question have to be compiled using Arch Build System (ABS) only then gdb works. Marking this as resolved because issue 'will not fix'. Thank you for your time.
Okay, no problem. I would like to help you with it, though you might be right that this might not be fixable on the evolution side, but rather on the glib side.
I have the same issue on Ubuntu 17.04 with Gnome3. libglib2.0-0 is up to date (libglib2.0-0).
FYI >> I am working around this problem as follows: 1. Before closing Evolution, put it to 'work offline' mode first then close the app. 2. Upon next restart, Evolution will start in offline so put it to online mode manually. The problem of halting at 'saving user interface...' won't be there. See if this helps.
Hi @MilanCrha, The workaround in my comment #10 is working very well and fixes the problem for next evo startup. >> Close Evolution in 'offline mode' > on start > wait 1 second > go online mode = No problem in looking up multiple accounts and all emails ** Do you think programming a delay on startup to replicate above will be a good idea? Of course it's not a proper fix but solves the problem ** Since 2013 this isn't fixed (for reasons) and likely prevent people from using evo as primary mail client specially when they have many mail accounts. Thanks.
(In reply to pingo from comment #11) > ** Do you think programming a delay on startup to replicate above will be a > good idea? Of course it's not a proper fix but solves the problem ** I won't go that way. According to my tests, it's a matter of luck whether the GTask's thread pool causes deadlocks or not. Any such workarounds are just going to cause more trouble than gain. Also, going to online due to network change already has 5 seconds time out, that's to avoid sudden connect attempts when the network is rapidly changing (there are issued many notifications about network change) after connecting to the network. You might better claim in bug #774448, to push it forward.