Bug#423238: Memory leak in fuse

2007-05-14 Thread Miklos Szeredi
 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]



Bug#423238: Memory leak in fuse

2007-05-10 Thread Chris AtLee
Package: fuse
Version: 2.6.3-4
Severity: normal

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.

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;


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.20-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]