Skip Menu |

This queue is for tickets about the Devel-Size CPAN distribution.

Report information
The Basics
Id: 124105
Status: resolved
Priority: 0/
Queue: Devel-Size

People
Owner: Nobody in particular
Requestors: zefram [...] fysh.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.82



Subject: sparse array test broken on 5.27.8
Date: Tue, 16 Jan 2018 19:13:55 +0000
To: bug-Devel-Size [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
A recent bugfix in bleadperl, commit 6661956a23de82b41adc406200054293d6d7aded, which is due to be released in Perl 5.27.8, causes Devel-Size to fail a couple of its tests. The failing tests are just testing for the old buggy behaviour, and need to be updated to accept the fixed behaviour. -zefram
On 2018-01-16 14:14:04, zefram@fysh.org wrote: Show quoted text
> A recent bugfix in bleadperl, commit > 6661956a23de82b41adc406200054293d6d7aded, which is due to be released > in Perl 5.27.8, causes Devel-Size to fail a couple of its tests. > The failing tests are just testing for the old buggy behaviour, and need > to be updated to accept the fixed behaviour.
Can you explain the increase of $array_2_size in the 1st failing test? Just looking at the number it looks like the new implementation takes more space.
Subject: Re: [rt.cpan.org #124105] sparse array test broken on 5.27.8
Date: Sat, 20 Jan 2018 21:54:23 +0000
To: Slaven_Rezic via RT <bug-Devel-Size [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Slaven_Rezic via RT wrote: Show quoted text
>Can you explain the increase of $array_2_size in the 1st failing test?
Array elements now get created slightly less lazily than they were before. In that test, I think the copying of @array is causing $array[1] to be created, hence using more space. The details of the new behaviour haven't been fully nailed down yet. The code got edited a second time before 5.27.8 came out, and this version has some inconsistent behaviour, so don't be surprised if it changes again for 5.27.9. There are two competing approaches for how to handle uses of non-existent array elements. One just creates them, which takes a small amount of time but only on the first use, takes memory for the element which persists with the array, and has a visible side effect if you use the discouraged exists($a[$i]). The other approach creates a magical placeholder, which takes a bit more time and takes that time repeatedly on each use, takes a bit more memory but only for the duration of the element usage, and has no side effect on exists(). -zefram
On Sat Jan 20 16:54:36 2018, zefram@fysh.org wrote: Show quoted text
> Slaven_Rezic via RT wrote:
> >Can you explain the increase of $array_2_size in the 1st failing test?
> > Array elements now get created slightly less lazily than they were before. > In that test, I think the copying of @array is causing $array[1] to be > created, hence using more space. > > The details of the new behaviour haven't been fully nailed down yet. > The code got edited a second time before 5.27.8 came out, and this > version has some inconsistent behaviour, so don't be surprised if it > changes again for 5.27.9. There are two competing approaches for how > to handle uses of non-existent array elements. One just creates them, > which takes a small amount of time but only on the first use, takes memory > for the element which persists with the array, and has a visible side > effect if you use the discouraged exists($a[$i]). The other approach > creates a magical placeholder, which takes a bit more time and takes > that time repeatedly on each use, takes a bit more memory but only for > the duration of the element usage, and has no side effect on exists(). > > -zefram
For reference, here is what I got for test failures against v5.27.7-216-ga590bf6 build on Jan 19 2018: ##### $ ~/testing/blead/bin/prove -I~/testing/blead/lib -vb t/recurse.t t/recurse.t .. 1..84 ok 1 - 4 pointers are dividable by 4 ... ok 53 - non-zero size for IV ok 54 - non-zero size for array with 1 element not ok 55 - gaps in arrays don't allocate scalars ok 56 - two arrays compare the same (same element count) ok 57 - two arrays compare the same (element 2) ok 58 - two arrays compare the same (element 1) ok 59 - two arrays compare the same (element 0) not ok 60 - assigning undef to a gap in an array allocates a scalar ok 61 - two arrays compare the same (same element count) ... # Failed test 'gaps in arrays don't allocate scalars' # at t/recurse.t line 240. # got: '168' # expected: '144' # Failed test 'assigning undef to a gap in an array allocates a scalar' # at t/recurse.t line 251. # got: '168' # expected: '192' # Looks like you failed 2 tests of 84. Devel::Size: Calculated sizes for compiled regexes are incompatible, and probably always will be Devel::Size: Calculated sizes for compiled regexes are incompatible, and probably always will be Devel::Size: Calculated sizes for compiled regexes are incompatible, and probably always will be Dubious, test returned 2 (wstat 512, 0x200) Failed 2/84 subtests Test Summary Report ------------------- t/recurse.t (Wstat: 512 Tests: 84 Failed: 2) Failed tests: 55, 60 Non-zero exit status: 2 Files=1, Tests=84, 0 wallclock secs ( 0.03 usr 0.02 sys + 0.06 cusr 0.00 csys = 0.11 CPU) Result: FAIL ##### Thank you very much. Jim Keenan
On 2018-01-20 16:54:36, zefram@fysh.org wrote: Show quoted text
> Slaven_Rezic via RT wrote:
> >Can you explain the increase of $array_2_size in the 1st failing test?
> > Array elements now get created slightly less lazily than they were before. > In that test, I think the copying of @array is causing $array[1] to be > created, hence using more space. > > The details of the new behaviour haven't been fully nailed down yet. > The code got edited a second time before 5.27.8 came out, and this > version has some inconsistent behaviour, so don't be surprised if it > changes again for 5.27.9. There are two competing approaches for how > to handle uses of non-existent array elements. One just creates them, > which takes a small amount of time but only on the first use, takes memory > for the element which persists with the array, and has a visible side > effect if you use the discouraged exists($a[$i]). The other approach > creates a magical placeholder, which takes a bit more time and takes > that time repeatedly on each use, takes a bit more memory but only for > the duration of the element usage, and has no side effect on exists().
This is still unfixed, either in perl or the module. I tried to create a more minimal test case: #!/usr/bin/perl use strict; use Devel::Size 'total_size'; use Devel::Peek 'Dump'; use Test::More 'no_plan'; my @a = (0); $a[2] = 2; my $before = total_size \@a; #Dump @a; is $a[1], undef; my $after = total_size \@a; #Dump @a; is $after, $before; __END__ This passes with perl 5.26.1, and fails with 5.27.10. On my system the total_size difference is 264 vs. 144. It seems that running Test::More::is on the non-existing array element triggers something in the newer perl. Before calling Test::More::is, Devel::Peek::Dump shows Elt No. 1 SV = 0 for both perl versions. In 5.26.1, this output does not change after calling Test::More::is, but in 5.27.10 it's now: Elt No. 1 SV = PVMG(0x1704870) at 0x101d5d0 REFCNT = 1 FLAGS = (SMG) IV = 0 NV = 0 PV = 0 MAGIC = 0x1016a20 MG_VIRTUAL = &PL_vtbl_nonelem MG_TYPE = PERL_MAGIC_nonelem(Y) Test::More version is 1.302133 in both perls.
Subject: Re: [rt.cpan.org #124105] sparse array test broken on 5.27.8
Date: Fri, 30 Mar 2018 21:27:03 +0100
To: Slaven_Rezic via RT <bug-Devel-Size [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Slaven_Rezic via RT wrote: Show quoted text
> Elt No. 1 > SV = PVMG(0x1704870) at 0x101d5d0
... Show quoted text
> MG_TYPE = PERL_MAGIC_nonelem(Y)
This is a new version of the logic for non-existent array elements, introduced in 5.27.9. You can expect this to be what gets released in 5.28. -zefram
RT-Send-CC: jkeenan [...] cpan.org
On 2018-03-30 16:27:24, zefram@fysh.org wrote: Show quoted text
> Slaven_Rezic via RT wrote:
> > Elt No. 1 > > SV = PVMG(0x1704870) at 0x101d5d0
> ...
> > MG_TYPE = PERL_MAGIC_nonelem(Y)
> > This is a new version of the logic for non-existent array elements, > introduced in 5.27.9. You can expect this to be what gets released > in 5.28.
The problem still exists with perl 5.28.0 RC1. And the module is quite high in the CPAN river.
On 2018-05-22 13:25:23, SREZIC wrote: Show quoted text
> On 2018-03-30 16:27:24, zefram@fysh.org wrote:
> > Slaven_Rezic via RT wrote:
> > > Elt No. 1 > > > SV = PVMG(0x1704870) at 0x101d5d0
> > ...
> > > MG_TYPE = PERL_MAGIC_nonelem(Y)
> > > > This is a new version of the logic for non-existent array elements, > > introduced in 5.27.9. You can expect this to be what gets released > > in 5.28.
> > The problem still exists with perl 5.28.0 RC1. And the module is quite > high in the CPAN river.
Thanks for the new release. I don't see any failures anymore with 5.28.0.
This can be resolved.