GNOME Bugzilla – Bug 697198
searching with criteria consumes 100% CPU
Last modified: 2017-08-15 22:20:14 UTC
I'm running Nautilus 3.8.0 on Ubuntu 13.04. To see the problem: 1. Configure Nautilus with --disable-tracker, build and install. 2. In Nautilus, navigate to a folder that has just a few files and no subfolders. 3. Press the magnifying glass icon to initiate a search. 4. Press the + button to show search criteria. You'll see "File Type - Any". Now all files will disappear from the view. Nautilus will display "Searching..." in the lower right corner and will peg the CPU at 100% indefinitely. If you modify the search criteria, the situation remains the same and Nautilus still shows no results.
I see this when built with tracker support enabled as well, with exactly the same steps and symptoms.
I found that "a folder that has just a few files and no subfolders" is not a requirement. I get the same result with whatever directory. I get this in the terminal after clicking the + button: ** (nautilus:8028): WARNING **: Provider NautilusSearchEngineTracker failed with error no such module: trackerfts
I can't reproduce this bug in my environment unfortunately, but the symptoms sound a lot like https://bugzilla.gnome.org/show_bug.cgi?id=692035. Which version of GTK are you guys testing this on? (In reply to comment #2) > I get this in the terminal after clicking the + button: > > ** (nautilus:8028): WARNING **: Provider NautilusSearchEngineTracker failed > with error no such module: trackerfts This seems an unrelated error with your tracker configuration.
I have libgtk 3.8.0.
I am testing from jhbuild on Fedora 18, tracking 3.8 moduleset, glib, gtk+ and nautilus cleanly rebuilt minutes ago. Still reproducible.
*** Bug 702797 has been marked as a duplicate of this bug. ***
Now it prints a warning: Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries The relevant GTK+ commit: https://git.gnome.org/browse/gtk+/commit/?id=c3bff30b504f80f9c8bc451bb5a73d1b0047b89f
I'm still seeing this with Nautilus from git master and GTK 3.10.6 on Ubuntu 14.04. One slight change: in my original description above I said that all files disappeared from the view. Now they are still visible when this occurs, and in fact searching works: I can type a search term to filter the files I see below. The CPU, however, is still churning away.
I think Cosimo hit the nail on the head here. This seems to be https://bugzilla.gnome.org/show_bug.cgi?id=692035 returning to haunt us. (https://bugzilla.gnome.org/show_bug.cgi?id=692035#c3) > The set_label_size_request() function at > http://git.gnome.org/browse/nautilus/tree/src/nautilus-pathbar.c?id=id=9a122cb3aa4f85548ff036ea3e6509e0e60387f8#n304 > is completely broken. Size requests must not modify widgets. > > So what happens is that unsetting ellipsisze will of course queue a resize on > the label which in turn will queue a resize on the pathbar. And when you do > that during size computation, size computation will cause a resize which will > cause a size computation. > > I have no idea why it used to work, but I'm convinced that was a lucky > accident. (https://bugzilla.gnome.org/show_bug.cgi?id=692035#c4) > This seems to have been fixed in GTK in the meantime. > That code has quite a long history in the pathbar; it's trying to make the > label request size as if it was bold, so that the button doesn't change size > when you click it... > > Anyway, not a problem anymore. I hope this won't be back at some point :) It's baaack. When is the label supposed to be bold anyways? I have never seen it bold. And is it really necessary to mess with the ellipsize property?
Created attachment 267326 [details] [review] Do not modify ellipsize property, just to confirm the issue
> It's baaack. When is the label supposed to be bold anyways? I have never seen it bold. I must have been half asleep here, I meant to say I haven't seen the pathbar labels ellipsize. I have seen it now though. Anyways, I'll post a patch in a minute.
Created attachment 269032 [details] [review] Rather than modifying the ellipsize property, we can use the natural size of the label
So the new patch ought to fix this. Basically instead of this: gtk_label_set_ellipsize (GTK_LABEL (button_data->label), PANGO_ELLIPSIZE_NONE); gtk_widget_get_preferred_size (button_data->label, &min_req, NULL); gtk_label_set_ellipsize (GTK_LABEL (button_data->label), PANGO_ELLIPSIZE_MIDDLE); We can do this: gtk_widget_get_preferred_size (button_data->label, NULL, &min_req); (Note the position of the min_req argument) Because the natural size of a label is already the non-ellipsized size.
Any chance this could be closed soon? (Hoping to pay bills this month) I think the patch works perfectly, it resulted in the same exact min_req as the old code when I tested it, but without the continuous layout CPU usage issue.
Thanks, I pushed this to git master.
I can still reproduce this bug. Steps to reproduce are: 1) click on magnifying glass icon 2) click on [+] button at the end of the search bar. Stack trace:
+ Trace 233250
Thread 1 (Thread 0x7ffff3f6ba40 (LWP 2915))
I cut the rest of the stack trace, with continues endlessly repeating the same pattern.
With some more time and patience, I reached the end of the stacktrace:
+ Trace 233251
@António: I can not reproduce this. I did the following: 1) git clone git://git.gnome.org/nautilus 2) cd nautilus 3) ./autogen.sh --prefix=/usr --sysconfdir=/etc \ --localstatedir=/var --disable-static \ --libexecdir=/usr/lib/nautilus \ --disable-nst-extension \ --disable-update-mimedb \ --disable-packagekit \ --disable-schemas-compile \ --disable-tracker (works either way...) 4) make 5) sudo make install 6) nautilus 7) Click the magnifying glass icon 8) Click the [+] button at the end of the search bar 9) (CPU usage is normal) Are you sure you're on the newest master? Running 'git log | grep fae9dde' should show the commit that fixed this.
(In reply to comment #18) > Are you sure you're on the newest master? That's correct. 1) nautilus -q 2) jhbuild buildone -fac nautilus 3) jhbuild run nautilus 4) Click the magnifying glass icon 5) Click the [+] button at the end of the search bar. I reopened this report because I can still reproduce it after the commit.
This crash is also reproducible by setting the scope to "All Files", without inserting a query beforehand: 1) $ nautilus -q 2) $ nautilus 4) Click the magnifying glass icon 5) Click the [ All Files ] button near end of the search bar. Tested on nautilus 3.12.0
The search interface completely redesigned was redesigned. This crash is no longer reproducible. The new search interface is already available in recent nautilus stable versions.