Kernel panic when unmounting an sshfs

[GoogleCodeExporter]

I just got a kernel panic when attempting to unmount an sshfs volume by 
clicking the eject button 
in a Finder window's sidebar. After I clicked it, nothing happened for several 
seconds (the 
computer didn't stall -- everything worked as usual, except it wasn't 
unmounting); then it froze.

Unfortunately, I can't really find a way to reproduce this, because I don't 
recall anything unusual 
about this instance... normally it works fine. But here's the panic log, if it 
helps at all.

panic(cpu 0 caller 0x5001727C): MacFUSE: vnode reclaimed with valid fufh 
(type=0, vtype=1)
Backtrace, Format - Frame : Return Address (4 potential args on stack) 
0x37043b28 : 0x128d08 (0x3cb134 0x37043b4c 0x131de5 0x0) 
0x37043b68 : 0x5001727c (0x5001d764 0x0 0x1 0x174f1f) 
0x37043be8 : 0x1e4d78 (0x37043c04 0x1 0x37043c28 0x35a3bf) 
0x37043c28 : 0x1d152f (0x6e6f948 0x37043c64 0x0 0x2) 
0x37043c88 : 0x1d1681 (0x6e6f980 0x6e6f948 0x14 0x3d3790) 
0x37043cd8 : 0x1d3d58 (0x6e6f948 0x37043d88 0x1 0x0) 
0x37043d48 : 0x1d4ff6 (0x61d1d00 0x0 0x19 0x65737566) 
0x37043da8 : 0x1d52d8 (0x61d1d00 0x0 0x0 0x5b281f4) 
0x37043dc8 : 0x1d539b (0x61d1d00 0x0 0x5b281f4 0x2e6e6f74) 
0x37043f58 : 0x379e23 (0x5b281f4 0x56095c8 0x560960c 0x0) 
0x37043fc8 : 0x19b17e (0x720e7a0 0x0 0x19e0b5 0x720e7a0) No mapping exists for 
frame 
pointer
Backtrace terminated-invalid frame pointer 0xbffffe48
      Kernel loadable modules in backtrace (with dependencies):
         com.google.filesystems.fusefs(0.2.5)@0x50011000

Kernel version:
Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST 2007; root:xnu-792.18.15~1/
RELEASE_I386

Model: MacBookPro2,1, BootROM MBP21.00A5.B01, 2 processors, Intel Core 2 Duo, 
2.33 GHz, 3 
GB
Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 256 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR2 SDRAM, 667 MHz
Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz
AirPort: AirPort Extreme, 1.0.47
Bluetooth: Version 1.7.14f14, 2 service, 1 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Network Service: Parallels Host-Guest, Ethernet, en2
Network Service: Parallels NAT, Ethernet, en3
Serial ATA Device: TOSHIBA MK2035GSS, 186.31 GB
Parallel ATA Device: MATSHITADVD-R   UJ-85J
USB Device: Built-in iSight, Micron, Up to 480 Mb/sec, 500 mA
USB Device: Bluetooth HCI, Up to 12 Mb/sec, 500 mA
USB Device: XSKey, Emagic GmbH, Up to 1.5 Mb/sec, 500 mA
USB Device: Apple Internal Keyboard / Trackpad, Apple Computer, Up to 12 
Mb/sec, 500 mA
USB Device: IR Receiver, Apple Computer, Inc., Up to 12 Mb/sec, 500 mA

Original issue reported on code.google.com by a...@atlas.st on 30 Apr 2007 at 2:49

[GoogleCodeExporter]

One instance of this same panic was reported in the macfuse-devel mailing list. 
This one is a programmatic 
panic (that is, it's panicing through an explicit call to the panic() routine 
in MacFUSE source, the reason being 
that a condition that "shouldn't be possible" is being hit). I haven't seen 
this myself and can't reproduce it. Before 
you attempted to unmount the volume, how had you been using it (what kind of 
I/O? reading/writing? what 
applications?)

Original comment by si...@gmail.com on 30 Apr 2007 at 3:09

[GoogleCodeExporter]

I think I was just using it to edit some files on my server. Text 
reading/writing, pretty much.

Original comment by a...@atlas.st on 30 Apr 2007 at 11:10

[GoogleCodeExporter]

This happened to me yesterday. Again, I was just unmounting the volume. No 
unusual
activity. The only thing I can think of is that there may have been files open 
at the
time.

Original comment by tchisl...@gmail.com on 6 May 2007 at 11:37

[GoogleCodeExporter]

OK, I can now reproduce this. Looks like the conditions based on which MacFUSE 
proactively panics are being 
generated because of a possible bug in Mac OS X. I can recreate the same 
conditions on Apple's WebDAV (iDisk) 
file system, but WebDAV doesn't proactively panic. For now, I'll remove the 
call to panic in the next release, so 
the result of hitting this condition won't be so drastic, although it'll still 
be "incorrect behavior". Needs more 
debugging and a better fix. Thanks for reporting this--this is a very weird one.

Original comment by si...@gmail.com on 7 May 2007 at 3:52

[GoogleCodeExporter]

The issue also exists with Apple's smbfs.

Original comment by si...@gmail.com on 7 May 2007 at 6:16

[GoogleCodeExporter]

This panic shouldn't occur with MacFUSE 0.3.0.

Original comment by si...@gmail.com on 7 May 2007 at 8:16

• Changed state: Fixed