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 548105 - nautilus crash when trying to unmount NFS drive if NFS server is down
nautilus crash when trying to unmount NFS drive if NFS server is down
Status: RESOLVED NOTGNOME
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.22.x
Other All
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-08-17 09:09 UTC by antoine
Modified: 2009-03-13 09:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description antoine 2008-08-17 09:09:25 UTC
Steps to reproduce:
This procedure involves 2 computers:
1. NFSServer
2. NFSClient

Step to reproduce:
1. Mounting an NFS disk on NFSClient
2. Shutting down the NFSServer
3. In nautilus/on the desktop, right clicking on the NFS disk and trying to unmount it
4. Nautilus crash

Stack trace:


Other information:
Reported on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/258734

Symptons:
After the crash, nautilus process is still active, but there are no icons on the desktop anymore, going to Places -> Home just doesn't work and there's no error message. Trying to execute nautilus trough a terminal doesn't work and gives no error

Workaround:
If you right clicked on the icon on the desktop: Go to System -> System Monitor -> Kill Nautilus
If you right clicked under nautilus: Close the window and confirm the fact that you want to kill process

After killing nautilus, everything works fine but the NFS drive is still mounted. Trying to access gives no result.
Comment 1 A. Walton 2008-08-18 14:52:01 UTC
Thanks for taking the time to report this bug.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 2 antoine 2008-08-18 15:45:17 UTC
Hi! I feel sorry, but I can't obtain backtraces. In fact Sebastien Bacher (see launchpad bug) thinks it is a hang rather than a crash. 

Here's what I did:
1. Mounting an NFS disk on NFSClient
2. Shutting down the NFSServer
3. Running gdb and attach it to nautilus
4. In nautilus/on the desktop, right clicking on the NFS disk and trying to
unmount it
4. Nautilus hangs: window becomes white, no icons on the desktop anymore. Trying to exit the program doesn't work, nor does 
5. couldn't obtain anything with gdb, so I killed the process and I couldn't obtain backtraces.

...
(gdb) continue
Continuing.
[New Thread 0x41720950 (LWP 23870)]
[New Thread 0x42722950 (LWP 23871)]
[Thread 0x41720950 (LWP 23870) exited]
[Thread 0x42722950 (LWP 23871) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) 
The program is not being run.
(gdb) backtrace full
No stack.



What is the difference between a crash and a hang? 
How could I give you useful informations in the case of a hang? 

Thank you!


Comment 3 Cosimo Cecchi 2008-08-21 10:51:08 UTC
I think this happens because we do sync i/o somewhere. Some sync i/o bugs were fixed in the 2.23 development cycle.
Can you try to reproduce the bug with Nautilus 2.23.90? (the current Ubuntu Intrepid development version ships it).
Comment 4 antoine 2008-08-21 14:35:56 UTC
Sure, I'll test with Ubuntu Interpid Ibex. But it 'll take some time because I have some exams to pass in the coming days. 
Moreover, Sebastien Bacher explained me how to get the backtraces in the case of a hang. I'll give you all those informations soon. 
Comment 5 antoine 2009-03-13 09:45:54 UTC
It seems the problem has nothing to do with nautilus. 

From, http://nfs.sourceforge.net/nfs-howto/ar01s04.html#mounting_remote_dirs:
mount options:
hard

    The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed (except by a "sure kill") unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. We recommend using hard,intr on all NFS mounted file systems. 


From Launchpad, comment of Peter Funk:

The problem (umount of a NFS volume of a disappeared NFS server is stuck in the kernel)
has nothing to do with a particular filemanager. This is only one possibility where the
symptoms of the problem surface.

I think this problem should be reported as a bug in the package nfs-common or the
Linux kernel, because even the /sbin/umount.nfs with option -f (force) given hangs
in the umount() system call, which can be seen by using the command
   strace -p `pidof /sbin/umount.nfs`
in another terminal window.


The bug should be closed