Kernel panic w/ sshfs 1.0.0, MacFUSE 1.7.0 (wiped file contents)

[GoogleCodeExporter]

What steps will reproduce the problem?

I use sshfs to edit text files on a FreeBSD server on a daily basis, with a 
medium activity level 
(save to disk at maximum a few times per minute, normally once every several 
minutes). A few 
minutes ago, I had a kernel panic immediately on saving a file. Since this has 
only happened 
once in the past month, I don't know what conditions might be necessary to 
reproduce it.

What is the expected output? What do you see instead?

A properly-written file would be the expected output, I guess. Instead, my 
machine panicked, 
and when I rebooted the machine and re-mounted the filesystem, the code I'd 
been working on 
had been turned into an empty file.

What version of the product are you using? On what operating system?

MacFUSE 1.7.0, sshfs 1.0.0 as downloaded from the project's downloads section. 
Mac OS X 
10.4.11 on a G4 Powerbook. I was editing the file with Aquamacs 1.4. I use 
MacFusion Version 
1.2 Beta 3 (1.1.268)  to manage/start sshfs connections.

Please provide any additional information below.

Here's the panic log:

Thu Aug 21 20:35:16 2008

Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x0000000039D49000 
PC=0x00000000000ACCE0
Latest crash info for cpu 0:
   Exception state (sv=0x39683280)
      PC=0x000ACCE0; MSR=0x00009030; DAR=0x39D49000; DSISR=0x40000000; 
LR=0x000AB618; R1=0x221ABA40; XCP=0x0000000C (0x300 - Data access)
      Backtrace:
0x000AB5D4 0x00273EC8 0x39C04E8C 0x00108D40 0x000FC538 0x000F57E8 
         0x0027F304 0x0027EF70 0x002ABDB8 0x000ABD30 0xFFFFFFFF 
      Kernel loadable modules in backtrace (with dependencies):
         com.google.filesystems.fusefs(1.7.0)@0x39c03000
Proceeding back via exception chain:
   Exception state (sv=0x39683280)
      previously dumped as "Latest" state. skipping...
   Exception state (sv=0x3885CC80)
      PC=0x900148AC; MSR=0x0000D030; DAR=0x399ED000; DSISR=0x40000000; 
LR=0x0005C66C; R1=0xF0203D10; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-
792.24.17~1/RELEASE_PPC
panic(cpu 0 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 0:
      Backtrace:
         0x000954F8 0x00095A10 0x00026898 0x000A8204 0x000ABB80 
Proceeding back via exception chain:
   Exception state (sv=0x39683280)
      PC=0x000ACCE0; MSR=0x00009030; DAR=0x39D49000; DSISR=0x40000000; 
LR=0x000AB618; R1=0x221ABA40; XCP=0x0000000C (0x300 - Data access)
      Backtrace:
0x000AB5D4 0x00273EC8 0x39C04E8C 0x00108D40 0x000FC538 0x000F57E8 
         0x0027F304 0x0027EF70 0x002ABDB8 0x000ABD30 0xFFFFFFFF 
      Kernel loadable modules in backtrace (with dependencies):
         com.google.filesystems.fusefs(1.7.0)@0x39c03000
   Exception state (sv=0x3885CC80)
      PC=0x900148AC; MSR=0x0000D030; DAR=0x399ED000; DSISR=0x40000000; 
LR=0x0005C66C; R1=0xF0203D10; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-
792.24.17~1/RELEASE_PPC

*********

Original issue reported on code.google.com by Nat...@gmail.com on 22 Aug 2008 at 1:10

[GoogleCodeExporter]

I can tell where the panic occurred, but without a way to reproduce this, 
there's no good chance of knowing how 
the system got there.

Original comment by si...@gmail.com on 25 Aug 2008 at 11:09

[GoogleCodeExporter]

Can't reproduce and haven't heard of any other reports of this. Try the latest 
developer release (and when the 
new stable release when it's out). Could also be a side effect of one of the 
lingering (unfixed) issues in Tiger 
itself. If so, we could be out of luck on Tiger.

Original comment by si...@gmail.com on 23 Oct 2008 at 7:31

• Changed state: WontFix