Bug 217135

Summary: nautilus loops consuming 100% CPU
Product: [Fedora] Fedora Reporter: Allan Engelhardt <allane>
Component: nautilusAssignee: Alexander Larsson <alexl>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-27 09:19:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Standard output and error for nautilus run #1
none
Backtrace from nautilus run #1
none
Output from nautilus run #2
none
Backtrace from nautilus run #2
none
Output from nautilus run #3
none
Backtrace from nautilus run #3
none
Multiple backtraces, as requested none

Description Allan Engelhardt 2006-11-24 08:32:31 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.0.8) Gecko/20061107 Fedora/1.5.0.8-1.fc6 Firefox/1.5.0.8

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):
nautilus-2.16.2-5.fc6.x86_64

How reproducible:
Always


Steps to Reproduce:
1. Start nautilus from the command line or Panel.
2.
3.

Actual Results:
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.


Expected Results:
It should work as before.

Additional info:
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

which gives

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.
Comment 1 Allan Engelhardt 2006-11-24 08:35:56 UTC 
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>
bt

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).
Comment 2 Allan Engelhardt 2006-11-24 08:36:38 UTC 
Created attachment 142042 [details]
Backtrace from nautilus run #1
Comment 3 Allan Engelhardt 2006-11-24 08:37:13 UTC 
Created attachment 142043 [details]
Output from nautilus run #2
Comment 4 Allan Engelhardt 2006-11-24 08:37:48 UTC 
Created attachment 142044 [details]
Backtrace from nautilus run #2
Comment 5 Allan Engelhardt 2006-11-24 08:38:30 UTC 
Created attachment 142045 [details]
Output from nautilus run #3
Comment 6 Allan Engelhardt 2006-11-24 08:39:12 UTC 
Created attachment 142046 [details]
Backtrace from nautilus run #3
Comment 7 Alexander Larsson 2006-11-24 08:43:54 UTC 
Strange.
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.
Comment 8 Allan Engelhardt 2006-11-24 08:50:25 UTC 
(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
/home/allane/Templates/openclipart-0.18-full (from
http://openclipart.org/downloads/0.18/openclipart-0.18-full.tar.bz2).

This appears to be the problem.

Doing a

$ 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).
Comment 9 Alexander Larsson 2006-11-24 08:54:39 UTC 
Ah, ~/Templates is a special directory that use used to create the template menu
for nautilus. Thats probably whats causing this.
Comment 10 Allan Engelhardt 2006-11-24 09:06:31 UTC 
Created attachment 142049 [details]
Multiple backtraces, as requested

Multiple backtraces from 

continue
^C
bt

in gdb, as requested
Comment 11 Allan Engelhardt 2006-11-24 09:09:43 UTC 
(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.
> 

Groan!

After renaming ~/Templates to ~/Clipart, nautilus is happy.

Not fair :-(  I hate surprises.