occasional kernel panics

[GoogleCodeExporter]

What steps will reproduce the problem?
at a guess, editing files remotely and doing a save.
I'm using TextMate and have it set to autosave when it loses focus.
maybe the crashes are coincidence, maybe not.

What is the expected output? What do you see instead?
a happy computer. the grey screen of death. 

What version of the product are you using? On what operating system?
macfuse .4, sshfs .3, Mac OS X 10.4.10 (PPC G5)

Please provide any additional information below.
I've attached a panic.log that shows a some crashes that point the finger
at fusefs

Original issue reported on code.google.com by carl.fo...@gmail.com on 6 Sep 2007 at 7:55

Attachments:

• panic.log

[GoogleCodeExporter]

According to  your log, the system ran out of memory (at least one type of 
memory pool). The said pool has 14 
*million* existing elements, which sounds, well, strange.

Can you think of any other software that might be using a lot of 
memory--especially kernel/wired memory? 
Any 3rd party kernel extensions?

How much RAM do you have?

Original comment by si...@gmail.com on 6 Sep 2007 at 10:36

[GoogleCodeExporter]

'strange' is rather understating the case, wouldn't you say? :-)

I've attached a listing of kernel extensions ( ls -lt 
/System/Library/Extensions/ )

My system has 1G of RAM, on two 512M cards.

If it helps, I typically have 1 sshfs file system mounted all the time. That 
is, from
login after boot until shutdown/reboot weeks later. During this time I often 
have 4
or more ssh sessions going at once and other sshfs drives to those systems are
mounted and unmounted.

Anything else I can tell you?

Original comment by carl.fo...@gmail.com on 7 Sep 2007 at 11:02

Attachments:

• kernel_extensions.txt

[GoogleCodeExporter]

The list of on-disk kernel extensions isn't very interesting or useful. You can 
list the currently loaded kernel extensions using the kextstat command.

 Any memory that MacFUSE directly allocates/deallocates, it keeps track of through built-in counters. You can look at such resource usage through the sysctl command:

$ sysctl macfuse.resourceusage
macfuse.resourceusage.filehandles: 1
macfuse.resourceusage.ipc_iovs: 10
macfuse.resourceusage.ipc_tickets: 5
macfuse.resourceusage.memory_bytes: 1925048
macfuse.resourceusage.vnodes: 4099
...

The values are summed across /all/ current MacFUSE mounts.

Anyway, I thought about your issue. Your log says the "kalloc.16" zone can't 
grow any more. This is a memory zone of 16-byte elements. If MacFUSE is the 
culprit in your 
case, we should be thinking of small objects that MacFUSE allocates. There are 
some: mutexes and read/write locks. However, MacFUSE doesn't directly allocate 
them: it 
calls the appropriate alloc/init functions in the locking KPIs to do this. 
Therefore, the memory behind these locks won't show up in the memory_bytes 
figure tracked by 
MacFUSE. Since the memory_bytes figure has typically looked good in my tests, I 
thought if MacFUSE might be leaking any locks/mutexes. And then I 
remembered--at 
one point, I added a couple of new locks. The idiom for dealing with these is 
something like:

lck_rw_alloc_init(...); // allocate and initialize
...
lck_rw_free(...); // destroy and free

However, there is also a lck_rw_destroy() function that destroys but doesn't 
free. In fact, lck_rw_free() simply calls lck_rw_destroy() and does just one 
additional thing: 
freeing.

In this instance, I must not have been paying enough attention and I used 
"destroy" instead of "free". Consequently, we were leaking a tiny amount of 
memory every time a 
vnode was destroyed. So, this is a bug.

I still find it impressive that you managed to exhaust all memory.

Lastly, thanks a lot for reporting this--MacFUSE is better because you ran into 
this (MacFUSE has tons of heavy users, and nobody has yet seen this). A fine 
bug indeed, 
and perhaps a reminder to me that I shouldn't add major features at 5 am.

It's fixed in the svn tree and will of course be fixed in the next binary 
release.

If you want to run a fixed build yourself, find 2 instances of lck_rw_destroy 
and 1 instance of lck_mtx_destroy in fuse_node.c. Change "destroy" to "free".

Original comment by si...@gmail.com on 8 Sep 2007 at 9:30

• Changed state: Fixed

[GoogleCodeExporter]

thanks for finding and fixing this so quickly. 
I've downloaded the source and XCode. I followed all the instructions in step 1 
of
the HOWTO to install it and rebooted. I'll let you know anything untoward 
happens.... 

Original comment by carl.fo...@gmail.com on 10 Sep 2007 at 10:00

[GoogleCodeExporter]

Actually, the HOWTO should be updated because the build instructions are now 
much simpler--almost trivial.

This is what you can do:

1. Checkout from subversion
$ svn checkout http://macfuse.googlecode.com/svn/trunk macfuse

2. Go to the appropriate subdirectory for your OS version
$ cd macfuse/core/10.5/

3. Build using the following command line
$ sudo xcodebuild -target All -configuration Release

This will build everything: the kernel extension, the library, utilities, etc. 
If everything went fine, you should 
have an installable package (MacFUSE Core.pkg) in 
/tmp/macfuse-core-10.5-0.5.0/. (The latter name will be 
different for a different OS/MacFUSE version).

Original comment by si...@gmail.com on 11 Sep 2007 at 12:45

[GoogleCodeExporter]

Correction: the cd should be to macfuse/core/10.5/fusefs/ and not 
macfuse/core/10.5/.

Original comment by si...@gmail.com on 11 Sep 2007 at 2:46