Skip Menu |

This queue is for tickets about the Test-Weaken CPAN distribution.

Report information
The Basics
Id: 46922
Status: resolved
Priority: 0/
Queue: Test-Weaken

People
Owner: jkegl [...] cpan.org
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 2.003_002
Fixed in:
  • 2.003_003
  • 2.003_004



Subject: false positive on unfilled array
Date: Sun, 14 Jun 2009 08:19:25 +1000
To: bug-Test-Weaken [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
With Test::Weaken 2.003_001 and recent debian i386 perl 5.10.0, a non-existant element in an array causes an unfreed_proberef to be returned. Sample failing test script and possible change below. (I noticed this with some of my code that has such part-filled arrays. It was ok with 2.002.)
--- Weaken.pm.orig 2009-06-13 18:30:23.000000000 +1000 +++ Weaken.pm 2009-06-13 18:39:19.000000000 +1000 @@ -88,7 +88,11 @@ FIND_CHILDREN: { if ( $object_type eq 'ARRAY' ) { - @child_probes = map { \$_ } @{$follow_probe}; + foreach my $i (0 .. $#$follow_probe) { + if (exists $follow_probe->[$i]) { + push @child_probes, \$follow_probe->[$i]; + } + } last FIND_CHILDREN; }
#!/usr/bin/perl package main; use strict; use warnings; use Test::Weaken; use Test::More tests => 4; { my $leaks = Test::Weaken::leaks(sub { my @array; $#array = 1; return \@array; }); ok(!$leaks, 'pre-extended array'); } { my $leaks = Test::Weaken::leaks(sub { my @array = (123, 456); delete $array[0]; return \@array; }); ok(!$leaks, 'array element delete()'); } { my @global; $#global = 1; my $leaks = Test::Weaken::leaks(sub { return \@global; }); ok(! exists $global[0], "leaks doesn't bring global[0] into existance"); ok(! exists $global[1], "leaks doesn't bring global[1] into existance"); } exit 0;
Thanks for catching this. This problem was a side effect of tracking array elements. I've uploaded 2.003_002, which fixes the problem with one restriction. Undefined array elements will no longer be tracked. Believe it or not, this is a real limitation -- you can get references to undefined elements separate from their array and you can create leaks with them if you put your mind to it. The problem is that it's very hard to deal with non-existent array elements without autovivifying them into undef's. A number of approachs are obvious, but I think you'll find each of them either copies some elements or autovivifies others, neither of which is acceptable. So I gave up. There are possible ways to do it. You could first test each element for existence, and keep that result in a array of flags with the same indices as the original array. Then, in a map block you can use a variable not local to the block to track the index which corresponds to the value of $_. I think map handles the elements in order, so that should work. That means you can use that index to determine if $_ exists or is merely undefined. I haven't tested this, it would be slow, it would be ugly and it would all be to make sure array elements don't leak, which is a bug, but one nobody ever noticed or reported. So my solution for now is to only track defined elements of arrays. On Sat Jun 13 18:19:54 2009, user42@zip.com.au wrote: Show quoted text
> With Test::Weaken 2.003_001 and recent debian i386 perl 5.10.0, a > non-existant element in an array causes an unfreed_proberef to be > returned. Sample failing test script and possible change below. > > (I noticed this with some of my code that has such part-filled arrays. > It was ok with 2.002.) >
Subject: Re: [rt.cpan.org #46922] false positive on unfilled array
Date: Tue, 16 Jun 2009 07:38:38 +1000
To: bug-Test-Weaken [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Jeffrey Kegler via RT" <bug-Test-Weaken@rt.cpan.org> writes: Show quoted text
> > you can get references to undefined > elements separate from their array and you can create leaks with them if > you put your mind to it.
Elements which exist but which happen to contain undef? Yep. Show quoted text
> either copies some > elements or autovivifies others, neither of which is acceptable.
Which way did the loop I posted fall? It seemed to do the trick; unless it needed some extra parens \($follow_probe->[$i]) maybe ...
On Mon Jun 15 17:39:05 2009, user42@zip.com.au wrote: Show quoted text
> Which way did the loop I posted fall? It seemed to do the trick; > unless it needed some extra parens \($follow_probe->[$i]) maybe ...
Actually, I hastily glanced at it and assumed that $follow_probe->[$i] would copy the array element, and not alias it. In response to your latest, I tested with Devel::Peek and you're right, it looks like it should work. I'll reimplement and retest for another developer's release. I'll add the parens, though. If we're asking each other whether they're needed, then they belong there regardless, is my philosophy.
I've just uploaded 2.003_003, which should fix this as well as RT#43855. I think the documents are ready for the major release also, so 2.003_003 is a release candidate. This version uses your fix for this bug. thanks
Classified as "unimportant" because it only affects developer's releases. It is, however, important this problem not get into any official release. This problem will be fixed in 3.000000, and is fixed in the latest developer's release: 2.003_005.
Actually, this is resolved. This bug (thank you for your vigilance, Kevin) affected only developer's releases, never made it into an official release, and is fixed in the last two developer's releases.
Subject: Re: [rt.cpan.org #46922] false positive on unfilled array
Date: Sat, 27 Jun 2009 09:39:05 +1000
To: bug-Test-Weaken [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Jeffrey Kegler via RT" <bug-Test-Weaken@rt.cpan.org> writes: Show quoted text
> > vigilance
Oh, well, test-weaken has been keeping me out of trouble on some widgets, and it caught an obscure but long-standing leak in a perl-glib xsub dispatch, so gotta try to give something back :-).
Fixed in 2.003_004 and after.