> There seems to be a memory leak somewhere in fuse. To reproduce: > > % cp /usr/share/doc/libfuse-dev/examples/fusexmp.c . > % (remove reference to config.h) > % gcc -Wall `pkg-config fuse --cflags --libs` fusexmp.c -o fusexmp > % mkdir test > % ./fusexmp test > % du -ms test & > % watch ps -C fusexmp -o pid,rss,cmd > > The resident size of fusexmp continues to grow. Not sure if fuse is > caching something on purpose, or if this is a real leak.
Yes, fuse is caching "nodes" and so a growing RSS is normal. You can check with valgrind, that that there's in fact no memory leak in this case. > This isn't unique to fusexmp either. The fusexmp_fh example, and sshfs > also do this. > > I did find one place where if fuse_do_getattr failed then memory > wouldn't be freed, but this didn't fix my problem. > > --- fuse-2.6.3.orig/lib/fuse.c > +++ fuse-2.6.3/lib/fuse.c > @@ -682,10 +682,10 @@ > break; > > res = fuse_do_getattr(f, req, newpath, &buf); > - if (res != 0) > - break; > free(newpath); > newpath = NULL; > + if (res != 0) > + break; > } while(--failctr); > > return newpath; This patch is definitely wrong. When we break out of the loop, the newpath needs to be set, and is actually freed in hide_node(). Freeing it within the loop would break the "unlink while open" semantics. Miklos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
