GNOME Bugzilla – Bug 710413
nautilus process sometimes uses 100% cpu
Last modified: 2013-12-15 11:45:37 UTC
On F20 (3.10.0) nautilus sometimes uses 100% cpu, I think this happens at startup, and maybe triggered by a search feature of shell, if possible, because I don't have nautilus running, as a window, just a process in the background. Also I think this is the same bug I tried to ask on IRC, then I used perf top -p $PID to check what is using it, it was some sqlite feature I think (not sure about name now, but it was related to databases). In case if nautilus is pressent as window, it works just fine. Now I did simple test while it is stuck at 100%, tried to search for some known files in gnome-shell (using shell search feature) I only get those files which are documents, but (like it is related to documents application?), no regular files. In system settings > Search > Files set to ON.
Bug 708648 and this one may be related.
Same problem here, happens about once a time. This is a major defect since I can not start a new instance of nautilus while nautilus is still running in background with 100% CPU load. It is only possible to start nautilus again when killing the invisible process (which is nothing a "normal" user might do). It has the command line /usr/bin/nautilus --no-default-window
I saw nautilus consistently using around 100% cpu yesterday. I didn't have any nautilus windows open at the time. I'm also on F20.
Is any of you using Kerberos via kinit or the Online Accounts panel?
No, I'm not using Kerberos (but krb5-libs is installed). Only IMAP, ICQ, Jabber and "people nearby" accounts via Gnome-Online-Accounts. No NFS or other fancy network stuff.
There's a downstream report here: https://bugzilla.redhat.com/show_bug.cgi?id=1026283 Can anyone who's seeing this follow the instructions from the 5th comment on that bug? > can you install debuginfo, and then when it's stuck in 100% cpu usage, get a > few backtraces ? > > something like > > for i in $(seq 1 3); do gstack $(pidof nautilus); done > three-stack-traces.txt I'd like to see if the traces point to tracker like in the downstream report.
Strange thing is: I haven't seen this bug for a while (~1…2 weeks). Will try a backtrace if it occurs again.
(In reply to comment #4) > Is any of you using Kerberos via kinit or the Online Accounts panel? I'm not using the Online Accounts panel, and not knowingly using kinit. I've heard anecdotal reports of this bug from a couple of other people, fwiw.
Are the people hitting this bug running sqlite 3.8.1 ? If so does downgrading it fix the problem?
I'm not using Kerebros. I have sqlite 3.8.1. Just like Christian on comment 7, I haven't seen this bug for a couple of weeks (formerly seeing it almost every day).
I am using Sqlite 3.8.1 since 2013-10-23. If this bug is related with sqlite at all, this update could have fixed it.
sqlite-3.8.1 is buggy, so running it will not fix anything. Instead it might have caused this bug, among others. So, can you downgrade to sqlite-3.8.0 and see if it is any better?
Created attachment 263025 [details] The requested stack traces (see comment #6) I ran $ for i in $(seq 1 3); do gstack $(pidof nautilus); done > three-stack-traces.txt as suggested in the other bug linked in #6. Still with up-to-date sqlite3, not downgraded (isn't provided any more by fedora repositories). I don't know if that is related, but: Before last reboot I cleaned the cache (~/.cache) which deleted tracker's database. Tracker crashed twice after that: 1. https://retrace.fedoraproject.org/faf/reports/217462/ 2. https://retrace.fedoraproject.org/faf/reports/27707/ and https://bugzilla.redhat.com/show_bug.cgi?id=882587
Oh, sorry: I am using sqlite 3.8.1-2, NOT 3.8.1-1. This bug occured with 3.8.0-? and 3.8.1-2, but not with 3.8.1-1 (the one being buggy).
Created attachment 263160 [details] again 100% CPU, this time different: I can still open/close windows, but they don't load (don't display any content)
Created attachment 263242 [details] The requested stack traces (see comment #6) Again 100% CPU on nautilus 3.10.1-2 with sqlite 3.8.1-2 and tracker 0.16.4-1 installed.
Possibly fixed: commit 00b71d0f9ae3f4d2b7bc8fa2afe08cd89c5c9c35 Author: Carlos Garnacho <carlosg@gnome.org> Date: Tue Dec 3 16:17:54 2013 +0100 fts: Strengthen against sqlite failures in FTS functions function_weights() and function_property_names() (used respectively by SPARQL fts:rank and fts:offsets functions), initialize all data at first from the database, so it's available in memory for posterior runs, although currently those are being quite optimistic about the database return values in several ways, so: - Ensure no infinite loops happen on sqlite3_step() if the stmt trips into some unexpected state. SQLITE_BUSY still does keep looping though. - As initialization here is a failable task, stop using g_once_init_* and use an static GMutex so initialization can be tried later again if it failed previously. - For the cases where initialization failed, propagate the error code on the sqlite3_context. Based on work by Tim Waugh and Michael Catanzaro. https://bugzilla.redhat.com/show_bug.cgi?id=1026283 I say "possibly" because I could not reproduce the original bug, even though I had hit it once recently. Plus we don't know who calls sqlite3_interrupt.
Created attachment 263432 [details] The requested stack traces (see comment #6) Again 100% CPU with nautilus. Using nautilus 3.10.1-2, sqlite 3.8.1-2, tracker 0.16.4-1
Assuming that you are running Fedora, the fix will eventually be in tracker-0.16.4-2.fc20.
*** Bug 719908 has been marked as a duplicate of this bug. ***