After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710413 - nautilus process sometimes uses 100% cpu
nautilus process sometimes uses 100% cpu
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
3.10.x
Other Linux
: Normal major
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 719908 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-17 19:23 UTC by Branko Grubic (bitlord)
Modified: 2013-12-15 11:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The requested stack traces (see comment #6) (63.95 KB, text/plain)
2013-11-28 14:40 UTC, Christian Stadelmann
Details
again 100% CPU, this time different: I can still open/close windows, but they don't load (don't display any content) (63.51 KB, text/plain)
2013-11-29 20:18 UTC, Christian Stadelmann
Details
The requested stack traces (see comment #6) (64.31 KB, text/plain)
2013-12-01 18:11 UTC, Christian Stadelmann
Details
The requested stack traces (see comment #6) (63.62 KB, text/plain)
2013-12-03 19:47 UTC, Christian Stadelmann
Details

Description Branko Grubic (bitlord) 2013-10-17 19:23:00 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.
Comment 1 António Fernandes 2013-10-17 20:38:16 UTC
Bug 708648 and this one may be related.
Comment 2 Christian Stadelmann 2013-10-26 19:46:17 UTC
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
Comment 3 Allan Day 2013-11-13 10:03:49 UTC
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.
Comment 4 Debarshi Ray 2013-11-20 17:02:39 UTC
Is any of you using Kerberos via kinit or the Online Accounts panel?
Comment 5 Christian Stadelmann 2013-11-20 17:15:12 UTC
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.
Comment 6 Ray Strode [halfline] 2013-11-20 18:35:21 UTC
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.
Comment 7 Christian Stadelmann 2013-11-20 18:47:11 UTC
Strange thing is: I haven't seen this bug for a while (~1…2 weeks). Will try a backtrace if it occurs again.
Comment 8 Allan Day 2013-11-21 09:30:32 UTC
(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.
Comment 9 Ray Strode [halfline] 2013-11-21 14:48:03 UTC
Are the people hitting this bug running sqlite 3.8.1 ? If so does downgrading it fix the problem?
Comment 10 António Fernandes 2013-11-21 15:24:29 UTC
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).
Comment 11 Christian Stadelmann 2013-11-21 17:56:18 UTC
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.
Comment 12 Debarshi Ray 2013-11-21 18:17:37 UTC
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?
Comment 13 Christian Stadelmann 2013-11-28 14:40:42 UTC
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
Comment 14 Christian Stadelmann 2013-11-28 14:53:24 UTC
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).
Comment 15 Christian Stadelmann 2013-11-29 20:18:53 UTC
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)
Comment 16 Christian Stadelmann 2013-12-01 18:11:59 UTC
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.
Comment 17 Debarshi Ray 2013-12-03 17:36:41 UTC
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.
Comment 18 Christian Stadelmann 2013-12-03 19:47:24 UTC
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
Comment 19 Debarshi Ray 2013-12-03 20:17:19 UTC
Assuming that you are running Fedora, the fix will eventually be in tracker-0.16.4-2.fc20.
Comment 20 António Fernandes 2013-12-15 11:45:37 UTC
*** Bug 719908 has been marked as a duplicate of this bug. ***