Red Hat Bugzilla – Bug 217135
nautilus loops consuming 100% CPU
Last modified: 2007-11-30 17:11:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:126.96.36.199) Gecko/20061107 Fedora/188.8.131.52-1.fc6 Firefox/184.108.40.206
Description of problem:
The nautilus file manager loops every time it is started, consuming a full CPU. I have let it run for a few minutes and it does not stop.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start nautilus from the command line or Panel.
Loops, consuming 100% of CPU. The application appears to be responding to normal commands, just *very*, *very* slowly. It practice it is unusable and cannot open a directory in 60 seconds.
From looking at top(1), the memory consumption appears to be increasing slowly.
It should work as before.
I will attach a few back traces and program output.
This is a new problem that did not appear on the original Zod installation. I tried to figure out a way to see what had changed; the best I could come up with is
$ rpm -q --last -f $(ldd $(which nautilus) | perl -ne 'print "$1\n" if (m/=> (\S+)/)' | sort -u) | uniq | head
nautilus-extensions-2.16.2-5.fc6 Thu 23 Nov 2006 21:16:43 GMT
gtk2-2.10.4-5.fc6 Thu 23 Nov 2006 21:16:27 GMT
GConf2-2.14.0-8.fc6 Tue 21 Nov 2006 16:04:39 GMT
eel2-2.16.1-1.fc6 Sat 11 Nov 2006 09:22:39 GMT
gnome-vfs2-2.16.2-1.fc6 Sat 11 Nov 2006 09:22:27 GMT
cairo-1.2.6-1.fc6 Fri 10 Nov 2006 08:52:13 GMT
librsvg2-2.16.1-1.fc6 Fri 10 Nov 2006 08:50:05 GMT
libX11-1.0.3-5.fc6 Fri 10 Nov 2006 08:49:50 GMT
libxml2-2.6.27-1.FC6 Fri 03 Nov 2006 18:28:51 GMT
pango-1.14.6-2.fc6 Fri 03 Nov 2006 18:28:37 GMT
I was trying to downgrade gtk2 and nautilus-extensions last night which is why the time is late. Of the two, gtk2 *is* genuinely a new update.
Created attachment 142041 [details]
Standard output and error for nautilus run #1
The application was started as
nice nautilus > nautilus-1.log 2>&1
The corresponding backtrace from
gdb attach <pid>
is in nautilus-bt-1.txt
Three runs are attached, each letting nautilus run for a little longer than
previous (about 10, 20, 60 seconds or so).
Created attachment 142042 [details]
Backtrace from nautilus run #1
Created attachment 142043 [details]
Output from nautilus run #2
Created attachment 142044 [details]
Backtrace from nautilus run #2
Created attachment 142045 [details]
Output from nautilus run #3
Created attachment 142046 [details]
Backtrace from nautilus run #3
Can you install gtk2-debuginfo, nautilus-debuginfo and then do a couple of more
backtraces. However, this time, don't wait so long between them.
Instead, when its taking 100%, press ctrl-c in gdb, get a backtrace, let it run
for a second, get another one, etc.
Collecting say 10 or so backtraces. This will give a crude idea of where
nautilus is spending its time.
(In reply to comment #5)
Interesting. The nautilus application was started in /home/allane and there is
a large directory of (PNG and SVG) images in
This appears to be the problem.
$ chmod a= /home/allane/Templates
causes nautilus to run normally.
The application should not be unresponsive because of large directories
(especially not when they are two levels removed from where it is working).
Ah, ~/Templates is a special directory that use used to create the template menu
for nautilus. Thats probably whats causing this.
Created attachment 142049 [details]
Multiple backtraces, as requested
Multiple backtraces from
in gdb, as requested
(In reply to comment #9)
> Ah, ~/Templates is a special directory that use used to create the template menu
> for nautilus. Thats probably whats causing this.
After renaming ~/Templates to ~/Clipart, nautilus is happy.
Not fair :-( I hate surprises.