GNOME Bugzilla – Bug 727387
Evo stuck with "Saving user interface state" on IPv6 system (multiple threads resolving DNS entries)
Last modified: 2015-03-05 12:54:44 UTC
I obtained IPv6 connectivity in my office. With IPv6 enabled on Fedora 20, evolution doesn't work, it starts up fine, but then gets stuck. After having killed the stuck process, I can reproduce every time, by starting evolution, and it displays "Saving user interface state" in the status bar. I tracked it down to the "outlook dbx import" plugin. With that plugin disabled, everything works fine.
Sigh. I take back "can reproduce every time". Someone it disappeard on its own. Previously, each time I tried, it was blocked for at least 20-30 seconds, when I got impatient. I had waited longer when I had seen it prevoiusly. Then, after enabling the plugin to reproduce again, I had to start evolution twice, until it got stuck with that status bar message (and while that one got displayed, I couldn't view any messages from any imap folders). Then, when it was in that "stuck" state, I ran a "gdb" batch command to obtain a stack trace. Evolution displayed the message for the entire duration the gdb batch command was running. Then I read the output. Then I went back to evolution, which was still running, but the status bar message was gone. Now, I cannot reproduce again. I'll send the stack trace by email to mcrha and mbarnes.
IIUC this is the source code for the dbx importer: https://git.gnome.org/browse/evolution/tree/plugins/dbx-import/dbx-importer.c
No, it's not caused by the dbx importer. I just reproduced the problem again. Even with all plugins disabled, it was stuck with "saving user interface state". As mcrha noted from a logfile I had passed to him (earlier), things were blocked with multiple threads attempting to resolve DNS entries. Now, again, I produced such a logfile, and I could again see the same state. However, it has helped to be patient. The stuck state disappeared after having waited for a few minutes.
evolution-data-server-3.10.4-3.fc20.x86_64 evolution-3.10.4-2.fc20.x86_64 evolution-ews-3.10.4-1.fc20.x86_64 evolution-rss-0.3.94-1.fc20.x86_64
Hello, I had a similar problem. It turns out that I had a DNS problem (one of my DNS didn't respond). I must admit that this problem is on my side. However, when the problem occured, I had a dozen of task "Saving user interface state". I think it would be nice if Evolution had just one "Saving user interface state" thread at time. thanks, Franklin P.S. I'm running Evolution on Debian/testing with: ii evolution 3.12.2-1+b1 ii evolution-common 3.12.2-1 ii evolution-data-server 3.12.2-1 ii evolution-data-server-common 3.12.2-1 ii evolution-plugins 3.12.2-1+b1
Thanks for a bug report. The thing is slightly complicated. With respect of the DNS queries, they use GLib's GTask interface. The "Saving user interface" also uses GTask interface (internally through GSimpleAsyncResult). The user interface changes (like changing folder in the folder tree) is done just by pushing a new GTask and remembering it, thus any further attempts are avoided due to pending ongoing activity. How you managed to have more user interface saving activities at once I do not know, possibly the activity got stuck in a state where it already set itself as done, thus the next activity with the user interface save could be run. Anyway, the fact that both DNS queries and user interface saving use GTask is important, because the GTask uses one global thread pool, with a limit of 10 threads. That makes the DNS ongoing queries eventually starve newly added GTask-s, like the one for user interface change save. That's the reason why the save stays in the status bar that long, it's just waiting to be processed through the queue of pending GTask-s. Evolution cannot influence where the DNS query will be done (whether to use GTask or not), similar the user interface change saving, though here except of avoiding GIO interface, which would work, but would also mean to duplicate some code from GLib/GIO and let it work in a way "good" for evolution. I do not think it would worth it.