GNOME Bugzilla – Bug 700283
duplicate search provider results
Last modified: 2013-08-06 09:50:19 UTC
Created attachment 244150 [details] contacts showing up three times. I sometimes get multiple instances of app results in overview search. Restarting shell fixes it.
Same with mine. confirmed by some users: https://bugzilla.gnome.org/show_bug.cgi?id=700719 https://bugs.archlinux.org/task/35026
*** Bug 700719 has been marked as a duplicate of this bug. ***
Created attachment 246110 [details] Background appears a dozen times I can confirm this issue. The duplicates are always present for me (it is not intermittent). Restarting gnome-shell does not resolve the problem. I believe it is even affecting search speed (speculation).
Alright, this fixed the problem for me (Arch Linux, gnome-shell 3.8.2). Reset your locale in every way possible: 1. edit /etc/locale.conf --- export LANG=en_US.UTF-8 2. edit /etc/locale.gen --- en_US.UTF-8 UTF-8 3. In a terminal, export locale vars and regenerate locales export LANG=en_US.UTF-8 export LC_MESSAGES="C" locale-gen 4. Go to Settings -> Region & Language - Change both "Language" and "Formats" 5. Reboot 6. Check output of `locale -a` and/or `locale` and make sure there are no errors, 7. Are there any errors? Repeat steps 1-5 in random order until there are no errors. 8. ... 9. No more duplicates! Whew! ...I think gnome-shell could still handle this situation a little better.
Tom, what is 'this situation' ? Your workaround does not really make it clear what you think was the problem in the first place. What was your locale settings before these changes ?
I definitely wasn't clear on that, sorry. The problem in the first place was inconsistent locale settings. When I looked in gnome-shell's Settings -> Region & Language, the page displayed "English" and "United States". This was inconsistent with what locale reported, which was something like: locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_GB.UTF-8 LC_CTYPE="en_GB.utf8" ... So to me, the 'situation' appears to be that gnome-shell will show duplicates if any locale files are missing. Before making all these changes, I'm fairly certain I had my locale setup for en_US.UTF-8 (by doing steps 1-3 as part of setting up the machine).
*** Bug 703749 has been marked as a duplicate of this bug. ***
*** Bug 696987 has been marked as a duplicate of this bug. ***
I've managed to reproduce this three or four times on my Chromebook. Unfortunately, it only happens really seldomly. I can't manage to debug it because it happens so little. If anybody can consistently reproduce this, is it possible for us to do some collaborative debugging? I found one bug, but I'm quite sure it's actually entirely unrelated and doubt it fixes the issue.
I just ran into this issue on a fresh fedora 19 install, it seems to do it for all searches. For example If I search for "downloads" I get the exact same result like 5 times :/ Strange thing is I didn't see the problem at all on my arch install with gnome 3.8.
and on my machine I don't appear to have locale issues. locale outputs: en_US.utf8 for everything and gives no error, and in gnome's language setting english us is selected for everything.
Well... I thought I could reproduce it reliably because the problem had persisted after multiple reboots, but after another reboot it mysteriously disappeared and now I can't seem to reproduce, so I guess you can count me in with the occurs at totally random group with jasper.
Created attachment 250175 [details] [review] search: Ensure that we correctly remove remote search providers When we reload the remote search providers, we currently try to remove all remote providers, and then re-scan. It turns out that we sometimes remove the wrong providers from the remote provider list, causing us to have some providers not correctly unloaded. --- This was the issue that I was talking about. I haven't managed to reproduce the issue with this patch applied, but I haven't managed to reproduce the issue *without* this patch applied, so oh well. It might fix the issue, it might not.
Review of attachment 250175 [details] [review]: I cannot verify whether this fixes this bug or not either (not easy to reproduce) but nevertheless the patch looks correct.
The source of the issue is that we're getting change signals from GSettings on startup (due to the way that dconf handles writes to itself that occur while registering a change monitor). This is probably caused by either tracker or g-s-d writing to dconf on login (see bug 694692 at least). The problem is the reload code: it removes all of the items (instantly) and then uses async calls to populate them again. The problem with that is that if you call it three times in a row, it will (immediately) remove all the search providers three times, then (in async result handlers) add them back three times. This is a bug, even aside from any (admittedly strange) dconf startup behaviour because you could have the same problem simply by doing two dconf writes quickly in a row.
Created attachment 250244 [details] [review] remoteSearch: Load remote search providers synchronously As we only reload search providers on startup or when the sort order changes, and given the small number of search providers we'll actually load, I doubt we'll see any speed decrease. The simplicity of synchronous code is also much clearer, and fully avoids all the possible bugs about in-flight requests or similar.
Review of attachment 250244 [details] [review]: The only comment I have here is that you should mention in the commit message that the error was caused by reloading configuration changes while loading the providers.
Attachment 250175 [details] pushed as 4efd363 - search: Ensure that we correctly remove remote search providers Attachment 250244 [details] pushed as be961cd - remoteSearch: Load remote search providers synchronously Pushed with suggested changes.
Can we backport this to 3.8 ?
Not yet. This is throwing exceptions on missing directories when iterating XDG_DATA_DIRS (like /usr/local/share/gnome-shell/search-providers).
https://git.gnome.org/browse/gnome-shell/commit/?id=a3236997bee6eb8b487c9e1d72379751da6ba0ae
I have the same issue. When I read this comment, I understood that have created some desktop file without [en_US] options like Icon[en_US] I have corrected those .desktop files, thats all. No Duplictaes now. (In reply to comment #4) > Alright, this fixed the problem for me (Arch Linux, gnome-shell 3.8.2). Reset > your locale in every way possible: > > 1. edit /etc/locale.conf > --- > export LANG=en_US.UTF-8 > > 2. edit /etc/locale.gen > --- > en_US.UTF-8 UTF-8 > > 3. In a terminal, export locale vars and regenerate locales > export LANG=en_US.UTF-8 > export LC_MESSAGES="C" > locale-gen > > 4. Go to Settings -> Region & Language > - Change both "Language" and "Formats" > > 5. Reboot > 6. Check output of `locale -a` and/or `locale` and make sure there are no > errors, > 7. Are there any errors? Repeat steps 1-5 in random order until there are no > errors. > 8. ... > 9. No more duplicates! Whew! > > ...I think gnome-shell could still handle this situation a little better.
(In reply to comment #22) > I have the same issue. When I read this comment, I understood that have created > some desktop file without [en_US] options like Icon[en_US] > > I have corrected those .desktop files, thats all. No Duplictaes now. Uhm, wait - some fields in desktop files are meant to be localized, like Name and Comment, others like Icon are not. So Icon[en_US] isn't strictly valid ...