Nautilus freezes when opening some directories

Bug #223912 reported by Sebastian Rühl
28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: nautilus

When I try to open some directories Nautilus just freezes.
It seems to be randomness as I had this Issue before when I tried to open my picture folder.
Now it seems to freeze everytime when I try to navigate to my eclipse workspace.
A killall nautilus bring back a working nautilus but when I want to go in the same directory it will freeze again.
How can I provide you with some traces?
Im using the latest updated Hardy (nautilus Version: 1:2.22.2-0ubuntu4)

here a snippet from .xsession-errors

Initializing nautilus-share extension
seahorse nautilus module initialized
Initializing nautilus-open-terminal extension
Nautilus-Share-Message: Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
Please ask your system administrator to enable user sharing.

hope that helps a bit.

Regards

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks for your bug report. For getting a backtrace you might want to look at http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. But according to the xsession-errors it looks that there's a problem in your smb configuration, can you check that first? thanks.

Changed in nautilus:
assignee: nobody → desktop-bugs
status: New → Incomplete
Revision history for this message
Sebastian Rühl (sebastian-ruehl) wrote :

unless Hardy doesn't install a samba server by default I don't have a smb configuration or I didn't touched it. However the smb.conf in the attachement...

Revision history for this message
mp (m-p) wrote :

not sure of this is the same bug:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/226746

????????

Revision history for this message
Sam_ (and-sam) wrote :

Hi,
confirm.
System: 2.6.24-16-generic amd_64 Hardy 8.04 LTS
Package: nautilus 1:2.22.2-0ubun
Package: metacity 1:2.22.0-0ubun (I don't use compiz.real)

Settings in nautilus: tree view left and list view right
Open nautilus navigate to /usr/share, click on the small arrow beside share to view folders in the tree view.
It shows loading, the cpu goes up to 100%, it doesn't open in the tree view.
Then move to another workspace and go back to this one with nautilus open.
The window is grey. Then close window and force to close. Nautilus closes and reopens immediately again with /home directory. (s. screenshots)

If instead of clicking the arrow you mark the folder /share it shows all the folders in the list view, although it takes an awful long time and cpu goes up to 100%.

No error messages in syslogs or var/crash, or when starting nautilus in a terminal.
Here is same looking output as above from xsession.errors
Also I dont' have any apport crash files in var/crash anymore since Hardy, even some apps had segfaults and crashed.
Additionally I tried to send manually a bug report from the applications menu+systemtools+send bugs but it didn't open.

I also have no samba installed and have no second machine to backtrace.
So in my view this all has something to do with the new PolicyKit, which didn't set the policy right after upgrading and outputs this warning in xsession.errors. I don't see how the settings should be if as a single user you get locked out from actions or do I need user sharing if I'm a single user?

output xsession.errors
Usage: apport-gtk [options]

apport-gtk: error: -c option requires an argument
Initializing nautilus-share extension
seahorse nautilus module initialized

** (nautilus:28006): WARNING **: Unable to add monitor: Nicht unterstützt
Nautilus-Share-Message: Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
Please ask your system administrator to enable user sharing.

Revision history for this message
Sam_ (and-sam) wrote :
Revision history for this message
Sam_ (and-sam) wrote :

Hi Pedro,
I've tried these commands and reproduced the steps I did describe above, but it didn't work. What is the right command? Thanks.
gdb nautilus 2>&1 | tee gdb-nautilus.txt
(gdb) handle SIG33 pass nostop noprint
(gdb) set pagination 0
(gdb) run

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Sam, that's described on https://wiki.ubuntu.com/Backtrace "Already running programs" section, thanks.

Revision history for this message
Sam_ (and-sam) wrote :

Hi Pedro,
thank you. I hope finally to made it correct know.

Revision history for this message
rihasant (riku.hs) wrote :

Same kind of bug happened to me while opening folder over ssh.

Revision history for this message
Sam_ (and-sam) wrote :

Hi,
I have no hint, but I don't have this issue anymore, maybe it was related to an update. Thanks anyway.

Revision history for this message
steven (yc-hecyy) wrote :

I still have this problem, i found that after i moved all the files with underscore filenames to a newly created sub-folder (by using the terminal) solves the problem

Revision history for this message
Sebastien Bacher (seb128) wrote :

could somebody describe easy steps to trigger the issue? the log attach before has no stacktrace

Changed in nautilus:
importance: Undecided → Medium
importance: Medium → Low
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Bah. I've seen random freeze when opening specific directories, but only with specific content (?), not eg. system directory. I had one directory with video files, and when I opened any subdirectory therein, Nautilus froze. First it took up something like 1G of memory for a second or two, then I got the compiz fade effect and needed to kill nautilus. This happened every time in spatial mode, where I could prevent the hang if I closed the previous directory's window quickly enough. But it did happen in non-spatial mode also, if I opened any file in those directories. Then again if I opened it with right click -> open with, it might not happen.

Now I moved the directory around to another subdirectory, and I cannot reproduce the problem anymore even in the spatial mode. I moved it around already before without able to fix the problem, but no somehow I've fixed the problem without knowing what I did.

So, there you go, I added exactly zero information to this bug, except for "Nautilus hangs in random weird ways sometimes when _opening_ something (directory/file)". I did not get anything meaningful in the logs, neither I was able to gdb enough when I tried.

If any of you have something reproducible on two machines, that would be a miracle already.

Revision history for this message
Saul D Beniquez (saullawl) wrote :

The same thing happens to me. Whenever I try to open my images folder, it freezes, and in the build/ directory of an scons project, it only does so when hidden files are switched on. I also found that if I create an image with the gimp while the folder I save it in is open, nautilus crashes. (at least in the scons directory)

I think has something to do with thumbnails, since turning them off seems to solve the problem.

Another clue as to the bug's properties is that I got a message regarding bonobo-activation-server's inability to find "the right factory", and that I should kill bonobo-activation-server and restart nautilus. This didn't work, but I believe that is evidence that the thumbnails are the culprit. I've tried deleting the thumbnails in ~/.thumbnails, but in the end the only thing that stops the bug is turning off thumbnails for all files.

Revision history for this message
Saul D Beniquez (saullawl) wrote :

Sorry to double post, but here is a proper backtrace from the nautilus-dbg package.

(I noticed Sam was having a little trouble with it. The trick is to use the bt command before killing the program. Since nautilus hangs, I had to use ctrl+c (SIGINTERRUPT) in order to do a bt. =])

Revision history for this message
Saul D Beniquez (saullawl) wrote :
Revision history for this message
Pedro Villavicencio (pedro) wrote :

the trace you attached is missing a lot of symbols please install the libgtk2,libglib2 and nautilus dbgsym packages and get a new one, thanks.

Revision history for this message
Saul D Beniquez (saullawl) wrote :

The bug stopped occuring.... and I don't know what I did to stop it - it just worked the next day.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Ok, closing the bug then, thanks.

Changed in nautilus:
status: Incomplete → Invalid
Revision history for this message
Sean (sproctor) wrote :

I am also experiencing this bug. Same symtoms, everything. Seems to be related to pictures. It takes about 5 minutes to open a nautilus window with just a few pictures. Uploaded a backtrace with debugging symbols.

Changed in nautilus:
status: Invalid → New
Revision history for this message
Sean (sproctor) wrote :

opened up the folder that freezes nautilus at 22:42:11. around 22:45:57 is where the window becomes responsive again.

Revision history for this message
Sean (sproctor) wrote :

sorry, I think I meant I opened the folder at 22:41:11 or thereabout.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the backtrace seems to indicate it's having issue on an image, can you try to figure which one and attach it to the bug?

Changed in nautilus:
status: New → Incomplete
Revision history for this message
Sean (sproctor) wrote :

As far as I can see this happens in every directory that has pictures. Do you have some idea on how to determine if one particular picture is causing the problem? Thank you.

Revision history for this message
Sebastien Bacher (seb128) wrote :

try starting on a directory which have no image, see if that's an issue, copy one there, refresh and see if that's an issue until getting the bug, then try if copying the one which triggered the issue in an another directory trigger the bug too?

Revision history for this message
Sean (sproctor) wrote :

The hangs are typically 4 - 5 minutes. and it only happens in my pictures directory. I have a directory with about 40 subdirectories with pictures. opening the top pictures directory is quick, but opening any subdirectory takes forever. if I create a new subdirectory and put a picture in it (either from elsewhere that loads quickly or one of the freezing picture subdirectories) it freezes. if I take any of the pictures from one of the pictures subdirectories and put it in a different directory outside of my pictures, it loads quickly. I hope that helps to explain the problem.

Revision history for this message
Sebastien Bacher (seb128) wrote :

no the description is not clear enough, what would be useful is steps to trigger the bug on a stock installation:

- start the current intrepid version on a new account
- create a directory and copy the image attached to the bug there
- open the directory in nautilus and notice it hangs

something around those lines would be useful

Revision history for this message
Sean (sproctor) wrote :

I assume that wouldn't cause a hang. It doesn't appear to be anything with one of the pictures. Copying my pictures directory to a new directory alleviates the problem. Another point of interest is that I have a custom icon for each folder that is a picture container within.

Let me try to list the known conditions:
- Happens when opening any subdirectory of $HOME/My Pictures
- Only happens if that subdirectory contains a picture
- The picture doesn't matter. Pictures that don't cause problems in other places cause problems in $HOME/My Pictures
- $HOME/My Pictures contains 56 subdirectories, each of them with a custom icon that is a picture from that subdirectory.
- $HOME/My Pictures does not freeze while loading.
- $HOME/My Pictures is world readable/writeable as are most of the subdirectories (were copied over from a windows partition)
- If I copy $HOME/My Pictures to $HOME/pictures, the problem (and custom icons) don't transfer over to $HOME/pictures.

If you look at the strace there appears to be a couple of files that appear unrelated but moving them out of the way didn't seem to help.
[pid 20274] 22:42:42.034784 open("/home/nicolle/My Pictures/2008.7/CIMG1528.JPG", O_RDONLY|O_LARGEFILE) = 22
..
[pid 20274] 22:42:42.469348 mmap2(NULL, 26546176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb1b1e000
[pid 20274] 22:43:53.849976 munmap(0xb1b1e000, 26546176) = 0

That picture is the icon for one of the subdirectories. Actually, all of the files in the strace are. Perhaps when I open a subdirectory all of the icons for $HOME/My Pictures are scaled? I'm grasping at straws. If you have any more ways I can analyze this, please let me know. Thanks for your patience.

Revision history for this message
Sean (sproctor) wrote :

I did a bit more debugging. I don't really get the code. From what I can understand: when I open up My Pictures, it finds the cached versions of the icons for all of the subdirectories. When I open up a subdirectory something causes it to check the icons for all of the subdirectories. For some reason it doesn't find them at this point. This happens in a thread that blocks interaction with the GUI. They're all custom icons, and some of them take 30 seconds to a minute to generate the thumbnails (I just stepped through and verified that's what's happening). That seems a bit extreme. Anyway, after that, that nautilus window will load any of the subdirectories again without problem, until it's closed. Once it's closed and reopened, back to not working. The backtrace helps to explain what's going on probably better than I did. Thanks.

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you look if the directory is listed in .config, user-dirs.dir? there was a similar bug recently saying that nautilus has issues on special dirs listed there in some cases

Revision history for this message
Sean (sproctor) wrote :

Nope.

.config/user-dirs.dir:
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Desktop"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/"
XDG_PICTURES_DIR="$HOME/"
XDG_VIDEOS_DIR="$HOME/Videos"

And the bug doesn't happen in $HOME. I don't understand the code well enough to figure out why the icons are being scaled ... it's making 16 pixel icons for something. From the parent directory of the directory I changed to (or the directory I'm changing away from, same thing). I don't see those icons anywhere. Also, it doesn't happen if I run "nautilus My Pictures/2001 Pawnee", while it would happen if I navigated to that directory. It seems that the generating of thumbnails is an unintended side-effect of something.

Revision history for this message
Sean (sproctor) wrote :

Is there anything else I can do to help resolve this? Should I also open a new bug about the certain pictures taking very long to scale?

Revision history for this message
Laurent (l-perlat) wrote :

Hi,
I have the same problem here I believe : greyed out nautilus windows + 100% CPU during 1-2 minutes.
If I kill nautilus during this time, then nautilus freezes forever next time I reopen the folder.

This started happening just after I added icons to folders in my Images directory.

Steps to reproduce :
One folder Images
Some sub-folders in Images
Navigate to one of these sub-folders
Drag and drop an image from a sub folder to the Information panel on the left
-> very fast
Navigate to parent folder, then another sub-folder
-> This takes a very long time with 100% CPU (1-2 minutes)
Navigate to parent folder
-> Again this takes a few minutes with window greyed out
Navigate anywhere
-> very fast
Go to another sub folder of Images and add a new icon to the sub-folder
-> Again 100% CPU during a long time
Kill nautilus while it is greyed out
Nautilus restarts
Navigate back to the sub folder containing the new icon folder (Images)
-> Nautilus greys out, taking 100% CPU forever
Kill nautilus, reopen, navigate back
-> Nautilus greys out, taking 100% CPU forever
Kill nautilus set an image as icon to another completely different directory
-> takes 1-2 minutes
Navigate back to the folder which made nautilus crash previously
-> takes 1-2 minutes but now it doen't freeze completely anymore
Navigate anywhere, close/reopen nautilus
-> very fast

So if I kill nautlius during the long freeze after adding an icon, navigating back to the folder after reopening nautilus freezes nautilus.
But if I add a new icon to another directory and let nautilus work during the few minutes, then the problematic folder opens fine next time i reopen nautilus.
So my workaround is just to never kill nautilus, even if it seems to be frozen after setting an image as folder icon..

Hope this helps,
Laurent

System : Ubuntu 8.04 with nautilus 1:22.2.5.1-0ubuntu1 (hardy proposed)

Revision history for this message
Laurent (l-perlat) wrote :

Sorry just missed a few words on step 5 :

Navigate to parent folder, then another sub-folder
should be :
Navigate to parent folder (Images), then to another sub-folder and set one of its images as folder icon

Laurent

Revision history for this message
CommanderCool (strodthoff-ymail) wrote :

Had this bug on my hardy 64 bit machine. Removing underscore-files solved the problem.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the bug has lot of comment and is confusing could somebody having the issue on intrepid summarize how to trigger the bug exactly there?

Revision history for this message
Sebastien Bacher (seb128) wrote :

does anybody still get the issue?

Revision history for this message
Sean (sproctor) wrote :

After upgrading to intrepid, I'm no longer seeing this issue. It seems this was a hardy-only bug.

The method for triggering the bug is dependent on the images. Some images take under a second to scale, some take closer to a minute.

Basically:
create a directory
create a bunch of subdirectories
put a bunch of images in all of those subdirectories (this step might be optional)
set the custom icon for each subdirectory as one of the images in that directory
navigate into one of the subdirectories
navigate back up to the parent directory (this is the step that causes the hang)

I think Laurent also described it fairly well.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

ok thanks you, marking this as fixed, feel free to re open it if you still see the issue with intrepid, thanks.

Changed in nautilus:
status: Incomplete → Fix Released
Revision history for this message
ticket (tickettothemoon2004) wrote :

Sorry to re-open - I confirm this bug is still there and agree with Saul D. B. When thumbnails (preview) are enabled, and you then enable viewing of hidden files, Nautilus freezes. It never used to do this, so no idea what has triggered it. I don't think it is connected to any folder type (home folder or otherwise). Disabling thumbnails cures the problem, but it is still a bug.

Interestingly, once the correct behaviour has been established, re-enabling preview again and toggling viewing of hidden files no longer caused a freeze - at least for now. Very difficult to pin this down.

Most definitley a problem with viewing hidden files when preview/thumbnails is on.

Nautilus 2.24.1
8.1 Intrepid
Linux 2.6.27-14-generic
GNOME 2.24.1

 Saul D. B. wrote on 2008-07-16: (permalink)

The same thing happens to me. Whenever I try to open my images folder, it freezes, and in the build/ directory of an scons project, it only does so when hidden files are switched on. I also found that if I create an image with the gimp while the folder I save it in is open, nautilus crashes. (at least in the scons directory)

I think has something to do with thumbnails, since turning them off seems to solve the problem.

Changed in nautilus (Ubuntu):
status: Fix Released → New
Changed in nautilus (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.