GNOME Bugzilla – Bug 698275
Enable/disable account yields to a several seconds busy loop
Last modified: 2014-11-18 13:57:19 UTC
When I enable or disable an IMAP account, the UI freezes for several seconds and I see 100% CPU use during that freeze. I enable/disable the account in Edit->Preferences->Mail Accounts by clicking the Enabled column's checkbox. I do not recall seeing this in the near past, and the only change I did was to create a new label named "[Gmail]/test" in evolution's labels, but even if I remove it I see the high CPU usage. Here's a backtrace for the main thread.
+ Trace 231811
Thread 1 (Thread 0x7fc4a4e64a00 (LWP 23384))
Created attachment 252519 [details] [review] evo patch for evolution; The main problem is e-settings-deprecated module, which writes values unconditionally, which makes GSetting notify about changes (even nothing changed), then it goes through the Preferences dialog and back to e-settings-deprecated module (or some such path). This patch does couple things: a) write values back to deprecated GSettings keys only if they really changed (how nice it would be if GSettings do this on their own) b) before updating EMailLabelListStore with a change from GSettings, check if anything changed at all - if not, then ignore the change c) add "changed" signal to EMailLabelListStore, thus the listener(s) can listen for it, instead of row-changed, row-inserted and row-removed, which is delivered on each single change, even when refilling store at b), for each single row added d) cumulate "changed" signal emission to idle, to cover as many consecutive notifications as possible. The changes are saved to GSettings just before the signal emission. According to my tests, the call of e_mail_shell_view_update_search_filter() decreased significantly with this patch.
Created commit 996055c in evo master (3.9.91+)
*** Bug 708602 has been marked as a duplicate of this bug. ***
In my duplicate report, I can disable and re-enable accounts without any delay. But I'm not able to compose a new message. Any chance to get a backport or a workaround to get Evo working again? :-p
You can always ask your distro maintainers to backport the patch to 3.8 (to which your bug is assigned). At least for me the issue happened only if I had opened Edit->Preferences, otherwise not - or not that often at least.
Not sure that's exactly the same bug... Are there some deprecated GSettings keys I can delete to work around this? Yes, I can request a backport in Fedora. It's sad that in every new release Evo gets both fixes and new showstopper bugs... :-/
(In reply to comment #6) > Not sure that's exactly the same bug... Are there some deprecated GSettings > keys I can delete to work around this? You cannot delete them, GSettings is more strict with compare of GConf. > Yes, I can request a backport in Fedora. Fedora? OK, I will build a test package for you (let's first test it, then create a real update if it'll work properly). > It's sad that in every new release Evo > gets both fixes and new showstopper bugs... :-/ I agree.
Great! ;-)
Maybe you are right, maybe you are not facing exactly the same bug (and/or there are multiple ways how to trigger this), because I realized that e-settings-deprecated.c/.h was introduced during 3.9 development cycle, thus it is not included in 3.8.x. Nonetheless, part of the patch still applies, thus I built a Fedora test package with it for you at: http://koji.fedoraproject.org/koji/taskinfo?taskID=5974745 In case it'll not help, please attach here labels.txt from this command: $ gsettings get org.gnome.evolution.mail labels >labels.txt though I'm not sure whether it'll help, because even you get a busy-loop on the labels update, the trigger of the fake 'changed' signal from the GSettings can be elsewhere. You can try to run: $ gsettings monitor org.gnome.evolution.mail and then open a composer window. The top of the output may give a clue where the flood begun. When I open a message composer (Ctrl+N in the Mailer view) then I do not see any activity from the GSettings monitor.
Funny. The first time I tried it hanged as before. But since I restarted it once again, the bug no longer happens. Even more funny: I downgraded Evo back to the Fedora version, and it still works. So either the patched version allowed a GSettings key to be changed once for all, or there was something else going on. The problem is, I also restarted gnome-shell because when I made Evo hang for the last time, it ate much RAM and I noticed gnome-shell was using too much RAM too, and actually I was experiencing hangs of my desktop during a few seconds for some time. So now I can't know whether this could be related or not... But the call to _gtk_tooltip_hide() in my stacktrace looks like it might, since tooltips are separate X windows, if I'm not mistaken. So thank you very much for the fixed package, now Evo works as before. But I'm not sure we really progressed in the understanding of this bug... :-/ For the record: $ gsettings get org.gnome.evolution.mail labels >labels.txt ['I_mportant:#EF2929', '_Work:#F57900', '_Personal:#4E9A06', '_To Do:#3465A4', '_Later:#75507B'] $ gsettings monitor org.gnome.evolution.mail Does not show anything when composing a new message (at least with the patched version).
(In reply to comment #10) > For the record: > $ gsettings get org.gnome.evolution.mail labels >labels.txt > ['I_mportant:#EF2929', '_Work:#F57900', '_Personal:#4E9A06', '_To Do:#3465A4', > '_Later:#75507B'] > > $ gsettings monitor org.gnome.evolution.mail > Does not show anything when composing a new message (at least with the patched > version). Pretty much the same here. Good it works for you, bad we didn't get too far with it (the package revert and restart should prove usefulness of the change, but as it begun to work properly for you even with older package, then I agree with you, it's really hard to tell).
I've observed a similar hang today with Evo 3.10.3 (Fedora 20) when trying to create a new event in the agenda. I have created several events in a row without trouble right before that, but then Evo hanged while opening the window for this one. Do you think it's the same bug? (gdb) ba
+ Trace 232945
(In reply to comment #12) > Do you think it's the same bug? I'm quite late here, I'm sorry, but it seems this cured itself during the time. At least I tried to reproduce it with glib2-2.38.2-2.fc20.x86_64 and gtk3-3.10.6-1.3.fc20.x86_64 and latest evolution (git master, after 3.13.1), and I cannot repeat it. My suspicious is that there happened some kid of ping-pong with change notifications on the GSettings side and widget side, and the two were not able to settle with correct value. This was the issue behind the change at comment #1. I mention glib2 here, because GSettings comes from there, thus they can also prevent this ping-pong. I do not have any exact change it there, I do not follow their changes at all, so it's possible nobody addressed this issue yet, still I do not seem to be able to reproduce it. Can you still reproduce this? Maybe I only miss some tiny detail which prevents the issue to trigger.
No, I've not seen it for a while on Fedora 20.
I made more aggressive changes in evolution to address these false change notifications. Created commit 2f3fbdd in evo master (3.13.3+) [1] Created commit 9a8950a in evo evolution-3-12 (3.12.3+) [1] https://git.gnome.org/browse/evolution/commit?id=2f3fbdd
(In reply to comment #15) > I made more aggressive changes in evolution to address these false change > notifications. > > Created commit 2f3fbdd in evo master (3.13.3+) [1] > Created commit 9a8950a in evo evolution-3-12 (3.12.3+) Ehm, the changes had a little regression, thus I made follow-up commits. There will be done one more change, this time for dconf/GSettings key change handlers, which can be called incorrectly too. Created commit 2e71c86 in evo master (3.13.3+) [2] Created commit 3e5ad92 in evo evolution-3-12 (3.12.3+) [2] https://git.gnome.org/browse/evolution/commit?id=2e71c86
The promised commits are (hopefully without regressions now): Created commit 6e9e7b0 in evo master (3.13.3+) [3] Created commit 7519575 in evo evolution-3-12 (3.12.3+) [3] https://git.gnome.org/browse/evolution/commit?id=6e9e7b0
*** Bug 726097 has been marked as a duplicate of this bug. ***