Skip Menu |
 

This queue is for tickets about the List-MoreUtils CPAN distribution.

Report information
The Basics
Id: 41494
Status: resolved
Priority: 0/
Queue: List-MoreUtils

People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: 0.400_003



Subject: memory leak in indexes() [XS]
Date: Sun, 07 Dec 2008 09:38:55 +1100
To: bug-List-MoreUtils [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 779b
With the debian packaged MoreUtils 0.22 and perl 5.10.0 the memory used by the program below grows apparently forever. If the two lines at the start are uncommented to use the pure-perl MoreUtils there's no memory growth. I suspect the ref count on the return values from List::MoreUtils::indexes() may be keeping them alive forever. (Incidentally, I saw the comments in MoreUtils.xs firstval() and lastval() referring to doing the same inc as in indexes(), but I believe those former two don't leak, as far as I can see. I guess the typemap for an SV* return does an sv_2mortal on it. I don't think the same on the multiple returns from indexes() would be enough though, since an error throw in the callback would still leak the returns built up but not yet mortalized.)
Download foo.pl
text/x-perl 252b
use strict; use warnings; # use Carp; # BEGIN { $ENV{LIST_MOREUTILS_PP} = 1; }; use List::MoreUtils; my @a = (10,11,12,13,14,15); print "odd numbers: ", (List::MoreUtils::indexes {$_&1} @a), "\n"; for (;;) { List::MoreUtils::indexes {$_&1} @a; }
This is resolved in 0.23 which I just uploaded to the CPAN.
Download (untitled) / with headers
text/plain 265b
On Sun Jul 12 14:44:50 2009, VPARSEVAL wrote: Show quoted text
> This is resolved in 0.23 which I just uploaded to the CPAN.
Note that the 0.23 code line is no longer in the latest release, 0.26. Consequently this and a number of other tickets in this queue are no longer resolved.
Subject: Re: [rt.cpan.org #41494] memory leak in indexes() [XS]
Date: Tue, 30 Nov 2010 09:24:30 +1100
To: bug-List-MoreUtils [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 921b
"Karen Etheridge via RT" <bug-List-MoreUtils@rt.cpan.org> writes: Show quoted text
> > Note that the 0.23 code line is no longer in the latest release, 0.26. > Consequently this and a number of other tickets in this queue are no > longer resolved.
Yes, this has regressed, indexes() leaks again in 0.26. The program below prints "still alive" where I expected it to print "weakened away". The latter is what it did in 0.25_02. This check could go in the test suite if it's not already there (for new enough perl to have weaken()). I suppose some care must be taken to mortalize at the right position, so the multicalls don't cause a free (if that is in fact the motivation for the extra SvREFCNT_inc), but an error throw out of the called test func does free. Perhaps a mortalized temporary AV could hold onto the results being built and either push them on the stack or mortalize them individually at the end after all the calls.
Download indexes-leak.pl
text/x-perl 222b
use strict; use warnings; use Scalar::Util; use List::MoreUtils 'indexes'; my $ref = \(indexes(sub{1}, 123)); Scalar::Util::weaken($ref); if (defined $ref) { print "still alive\n"; } else { print "weakened away\n"; }
Download (untitled) / with headers
text/plain 100b
I've disabled the XS version in 0.27_04 until C people have a chance to fix the XS version properly.
Subject: Re: [rt.cpan.org #41494] memory leak in indexes() [XS]
Date: Sat, 11 Dec 2010 09:51:32 +1100
To: bug-List-MoreUtils [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 542b
"Adam Kennedy via RT" <bug-List-MoreUtils@rt.cpan.org> writes: Show quoted text
> > I've disabled the XS version in 0.27_04 until C people have a chance to > fix the XS version properly.
Don't leave it that way. I had the misfortune to use the plain perl bits for a while for past bugs and it's a noticeable slowdown on medium-large data. The temp refcounts aren't difficult (unlike the nonsense about the multicalling in different versions of perl or whatever it was), and the code before was actually almost close enough, only leaking on an error throw.
Download (untitled) / with headers
text/plain 926b
On Fri Dec 10 17:52:26 2010, user42@zip.com.au wrote: Show quoted text
> "Adam Kennedy via RT" <bug-List-MoreUtils@rt.cpan.org> writes:
> > > > I've disabled the XS version in 0.27_04 until C people have a chance to > > fix the XS version properly.
> > Don't leave it that way. I had the misfortune to use the plain perl > bits for a while for past bugs and it's a noticeable slowdown on > medium-large data. The temp refcounts aren't difficult (unlike the > nonsense about the multicalling in different versions of perl or > whatever it was), and the code before was actually almost close enough, > only leaking on an error throw.
I care about that when I found a tuit (after fixing some other RT's on other modules). Please be patient. The current confusing forces Adam to walk this way to put L::MU on a clear base and have all RT's in a defined state so that I can pick the remaining tasks. Thank you very much, Adam and Kevin, Jens
Download (untitled) / with headers
text/plain 143b
I added some more tests to current trunk and don't see any of the described leaking behavior anymore. I tend it has been fixed in the meantime.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.