Skip Menu |

This queue is for tickets about the Fuse CPAN distribution.

Report information
The Basics
Id: 77321
Status: resolved
Priority: 0/
Queue: Fuse

People
Owner: Nobody in particular
Requestors: CYGA [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 0.14
  • 0.15.1
Fixed in: 0.16



Subject: memory leak
Sample script I attached (mem2.pl) leaks on simple ls. I also attached log for output: $ for i in `seq 1024`;do ls /tmp/fuse-mem-test 2>&1 1>/dev/null; ps faux | grep mem2 | grep perl | grep -v grep; done 2>&1 | tee -a mem.log Checked in 0.14 from metacpan/cpan, and in 0.15.1 from github (https://github.com/dpavlin/perl-fuse). Sample script returns hardcoded stats entry. And 1024 such entries in readdir. So, even if we consider it loads 1024 such entries in memory, it still keeps eating memory on new ls calls. Since structures are all the same, it's definitely a leak.
Subject: mem2.pl
#!/usr/bin/perl -w use strict; use Fuse; my $mount_point = shift @ARGV; my $dumb_attr = [ 0, # dev 1102499, # ino 17917, # mode 1, # nlink 0, # uid 0, # gid 0, # rdev 0, # size 1332539095, # atime 1332206658, # mtime 1326627143, # ctime 1024, # blksize 1, # blocks ]; sub getattr_fs { return @$dumb_attr } sub readdir_fs { return (0) if 1024 == $_[1]; return ( [ 1+$_[1], 'a', $dumb_attr, ], 0, ); } eval { Fuse::main( mountpoint => $mount_point, mountopts => 'allow_other', 'getattr' => 'main::getattr_fs', 'readdir' => 'main::readdir_fs', threaded => 0, ); }; die "$mount_point error: " . $@ if $@;
Subject: mem.log

Message body is not shown because it is too large.

Any plans for fixing it? On Mon May 21 03:52:31 2012, CYGA wrote: Show quoted text
> Sample script I attached (mem2.pl) leaks on simple ls. > I also attached log for output: > $ for i in `seq 1024`;do ls /tmp/fuse-mem-test 2>&1 1>/dev/null; ps
faux Show quoted text
> | grep mem2 | grep perl | grep -v grep; done 2>&1 | tee -a mem.log > > Checked in 0.14 from metacpan/cpan, > and in 0.15.1 from github (https://github.com/dpavlin/perl-fuse). > > Sample script returns hardcoded stats entry. > And 1024 such entries in readdir. > So, even if we consider it loads 1024 such entries in memory, > it still keeps eating memory on new ls calls. > Since structures are all the same, it's definitely a leak.
Any response? On Fri Jun 01 00:28:49 2012, CYGA wrote: Show quoted text
> Any plans for fixing it? > > On Mon May 21 03:52:31 2012, CYGA wrote:
> > Sample script I attached (mem2.pl) leaks on simple ls. > > I also attached log for output: > > $ for i in `seq 1024`;do ls /tmp/fuse-mem-test 2>&1 1>/dev/null; ps
> faux
> > | grep mem2 | grep perl | grep -v grep; done 2>&1 | tee -a mem.log > > > > Checked in 0.14 from metacpan/cpan, > > and in 0.15.1 from github (https://github.com/dpavlin/perl-fuse). > > > > Sample script returns hardcoded stats entry. > > And 1024 such entries in readdir. > > So, even if we consider it loads 1024 such entries in memory, > > it still keeps eating memory on new ls calls. > > Since structures are all the same, it's definitely a leak.
>
After some poking around, I believe I isolated the issue that was causing the problem. Can you try the current git master branch and see if that addresses the problem? See commit https://github.com/dpavlin/perl-fuse/commit/071831e39677044477b56895ce8ff3ef9a8849e7 for details. -- Derrik Pates demon@now.ai
On Fri Aug 30 20:43:17 2013, DPATES wrote: Show quoted text
> After some poking around, I believe I isolated the issue that was > causing the problem. Can you try the current git master branch and see > if that addresses the problem? > > See commit https://github.com/dpavlin/perl- > fuse/commit/071831e39677044477b56895ce8ff3ef9a8849e7 for details.
I tried the latest version (with "Okay, those sv_2mortal()s were bad.") - same test works great. Those: + SP -= prv - 1; make perfect sense. Will apply it on production. Thanks.