SSHFS: kernel panic with rename followed by write

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Mount a filesystem using sshfs (I used the sshfs 0.1.0 GUI)
2. Rename a file in the mounted volume (I did this using mv in a shell)
3. Open the renamed file and edit it (I used TextMate)
4. Save the file

Expected: file is saved.  Actual: Kernel panic.

I'm using MacFUSE core 0.2.1 and the sshfs 0.1.0 binary with GUI.  The
machine is an MBP Core Duo (not C2D) with OS X 10.4.8.

FWIW, the first time this happened, I renamed the file in TextMate and got
the panic on save.  Then I tried it again with the same result.  Then I
tried renaming in the shell and opening/editing in TextMate -- also the
same result.

If I ssh into the server and rename the file there, then TextMate can open
it and edit it no problem.

If there's any other scenario you'd like me to try, please let me know.

Original issue reported on code.google.com by rhett.su...@gmail.com on 23 Feb 2007 at 5:29

[GoogleCodeExporter]

I forgot the panic log.  Here's a representative one:

Wed Feb 21 20:56:14 2007
panic(cpu 0 caller 0x001D0B98): vnode_rele_ext: vp 48b6000 usecount -ve : -1
Backtrace, Format - Frame : Return Address (4 potential args on stack) 
0x252b3a68 : 0x128d1f (0x3c9540 0x252b3a8c 0x131df4 0x0) 
0x252b3aa8 : 0x1d0b98 (0x3d1c88 0x48b6000 0xffffffff 0x1e60a0) 
0x252b3ae8 : 0x1d0d21 (0x48b6000 0x0 0x0 0x0) 
0x252b3b08 : 0x1deb4f (0x48b6000 0x23 0x252b3f44 0x252b3b38) 
0x252b3b68 : 0x1e1031 (0x252b3f44 0x252b3e80 0x15 0x0) 
0x252b3ce8 : 0x1db9d2 (0x48b6084 0x252b3e80 0x252b3f00 0x0) 
0x252b3f68 : 0x378337 (0x48907d0 0x445b848 0x445b88c 0x0) 
0x252b3fc8 : 0x19acae (0x47a4bd4 0x0 0x206 0x37dafb4) No mapping exists for 
frame pointer
Backtrace terminated-invalid frame pointer 0xbffff018

Kernel version:
Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006;
root:xnu-792.13.8.obj~1/RELEASE_I386

Original comment by rhett.su...@gmail.com on 23 Feb 2007 at 5:31

[GoogleCodeExporter]

Supposing that you renamed a file named "A" to "B":

1. Was "A" open in TextMate (or any other program) when you renamed it?
2. Did "B" already exist (and you overwrote it with "A")?
3. If "B" did exist, was "B" open in TextMate or any other program?
4. Is TextMate configured to do "atomic saves"? (The checkbox at the bottom in 
Preferences->Advanced).
5. What's the output of the following command in the Terminal:
sysctl macfuse.version.string
6. What's the operating system of the ssh server involved?
7. Is this sporadic or can you reproduce this predictably?

Original comment by si...@gmail.com on 23 Feb 2007 at 6:00

[GoogleCodeExporter]

FYI, your panic is identical to the one reported here (also with MacFUSE):

http://groups.google.com/group/macfuse-devel/browse_thread/thread/0de8694e951b42
ee

However, there's a possibility that this might be an issue with Mac OS X in 
general, because I found some 
instances of panic in setxattr (what's happening in this case) while saving 
with TextMate:

http://lists.macromates.com/pipermail/textmate/2005-September/005288.html

Original comment by si...@gmail.com on 23 Feb 2007 at 6:10

[GoogleCodeExporter]

I had the very same problem:
1- A and B *not* open in Textmate
2- B does *not* already exist
4- TextMate *not* configured to do "atomic saves"
5- macfuse.version.string: 0.2.2, Feb 25 2007, 14:06:38
6- Linux / Debian, I think
7- Predictably

I followed the indication given there : 
http://lists.macromates.com/pipermail/textmate/2005-September/
005288.html and it solved the problem.

Original comment by herve.br...@gmail.com on 27 Feb 2007 at 9:06

[GoogleCodeExporter]

In response to comment #2:

1. I saw the panic both ways -- if I renamed the file through TextMate (and 
therefore
it was open) or if I renamed it and then opened it.
2. B did not already exist
3. N/A
4. Not using atomic saves
5. macfuse.version.string: 0.2.1, Feb 15 2007, 14:52:57
6. The SSH server is OpenSSH running on Ubuntu Linux
   "OpenSSH_4.2p1 Debian-7ubuntu3.1, OpenSSL 0.9.8a 11 Oct 2005"
7. Predictably

Original comment by rhett.su...@gmail.com on 4 Mar 2007 at 9:01

[GoogleCodeExporter]

There's some code in Apple's xnu-792.13.8 vfs_xattr.c that looks like a 
possible culprit. I've bugreported it 
as Radar # 5044984.

In vfs_xattr.c:818 if the call to default_removexattr() fails, then "goto out;" 
is executed. close_xattrfile() is 
then executed a second time for the xvp vnode_t. This leads to vnode_rele() 
being called twice.

xvp->v_usecount will eventually end up being negative (possibly when the file 
is closed), causing a panic 
at vfs_subr:1395:
"panic(cpu 0 caller 0x001D0B98): vnode_rele_ext: vp 6344ce4 usecount -ve : -1"

http://matt.ucc.asn.au/xnu/vfs/ has the xnu vfs source mirrored.

Original comment by matt@ucc.asn.au on 7 Mar 2007 at 4:50

[GoogleCodeExporter]

I was running it with an ssh mounted drive.  I used Aquamacs to simply look at 
some
files and after playing with looking at 8 or 9 files I got a screen telling me 
to
reboot.  I attached the report:

Original comment by foert...@gmail.com on 4 Apr 2007 at 7:26

Attachments:

• [kernel panic.rtf](https://storage.googleapis.com/google-code-attachments/macfuse/issue-111/comment-7/kernel panic.rtf)

[GoogleCodeExporter]

This Mac OS X bug is fixed in a certain upcoming version of the operating 
system.

Original comment by si...@gmail.com on 23 Jun 2007 at 6:11

• Changed state: Invalid