Kernel panic w/ sshfs 1.0.0, MacFUSE 1.7.0 (wiped file contents)
Closed this issue · 2 comments
GoogleCodeExporter commented
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 commented
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 commented
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