Reproducible panic in fuse_vnop_lookup via stat on sshfs

[GoogleCodeExporter]

I can reproduce this by doing a checkout then status of a Monotone version 
control tree.

1. Grab http://venge.net/monotone/downloads/mtn-0.32-osx-univ.bz2 binary, 
bunzip2 it to ~/
bin/mtn and chmod +x it.
2. Grab a sample repository file http://matt.ucc.asn.au/crash-fuse.mtn , put it 
somewhere local 
like ~/Desktop.
3. "mkdir ~/Desktop/test_dir ~/Desktop/mount_point"
4. "sshfs localhost:~/Desktop/test_dir ~/Desktop/mount_point"
5. "cd ~/Desktop/mount_point"
6. "~/bin/mtn --db=~/Desktop/crash-fuse.mtn co -b test.crash.macfuse1"
   The tree will be checked out to test.crash.macfuse1
7. "cd test.crash.macfuse1"
8. "~/bin/mtn status"

Expected result is "no changes" etc

Actual result is a kernel panic, panic log is attached as "dump1". If I try and 
do "mtn status" 
without the checkout, the panic doesn't occur (at least as I've tested).

What version of the product are you using? On what operating system?
Mac OS X 10.4.8 (8L2127) on a 1.83 MacBook, macfuse r39, fuse-2.6.1, 
sshfs-fuse-1.7 installed 
as per the howto.

See attached lookup_disasm.txt for the disassembled function, with the crash 
offset 0x4700 
marked. From what I can tell this is somewhere around fuse_vnops.c:843, though 
I'm not 100% 
sure.

I can provide other details if required.

The backtrace decodes to:

(gdb) x/i 0x19a8d4
0x19a8d4 <trap_from_kernel+19>: mov    %edi,%esp
(gdb) x/i 0x4052b700
0x4052b700 <fuse_vnop_lookup+336>:      mov    %eax,(%esp)
(gdb) x/i 0x1e2df1
0x1e2df1 <VNOP_LOOKUP+113>:     mov    %eax,%ebx
(gdb) x/i 0x1cab0b
0x1cab0b <lookup+538>:  mov    %eax,%edi
(gdb) x/i 0x1cb331
0x1cb331 <namei+559>:   mov    %eax,%esi
(gdb) x/i 0x1d7040
0x1d7040 <stat2+82>:    mov    %eax,%ebx

Original issue reported on code.google.com by matt.gtalkfix@gmail.com on 12 Jan 2007 at 7:45

Attachments:

• dump1
• lookup_disasm.txt

[GoogleCodeExporter]

Original comment by si...@gmail.com on 12 Jan 2007 at 8:18

• Changed state: Accepted

[GoogleCodeExporter]

I made a change to fusefs/fuse_node.c in the kernel extension source. Could you 
please checkout the latest 
fusefs source (revision 66 at this writing) and see if it fixes your issue?

Original comment by si...@gmail.com on 12 Jan 2007 at 9:31

[GoogleCodeExporter]

Yep, that seems to fix the panic. Many thanks.

Original comment by matt.gtalkfix@gmail.com on 12 Jan 2007 at 11:27

[GoogleCodeExporter]

Yep, that seems to fix the panic. Many thanks.

Original comment by matt.gtalkfix@gmail.com on 12 Jan 2007 at 11:31

[GoogleCodeExporter]

Original comment by si...@gmail.com on 12 Jan 2007 at 4:56

• Changed state: Verified