Latest Strawberries: addresses reported by "p", Devel::Peek, etc.

[Anonymous Monk]

use strict;
use Devel::Peek;
$Devel::Peek::pv_limit = 3;
use warnings;
printf "$^V\n";
my $s = 's' x 32;
Dump $s;
my $addr = pack 'p', $s;
printf "Q: hex: %x, dec: %1\$d\n", unpack 'Q', $addr;
Dump $s;

__END__

v5.32.1
SV = PV(0x1fbf48) at 0x24f0e08
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x2565cb8 "sss"...\0
  CUR = 32
  LEN = 34
Q: hex: 2565cb8, dec: 39214264
SV = PV(0x1fbf48) at 0x24f0e08
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x2565cb8 "sss"...\0
  CUR = 32
  LEN = 34

v5.42.0
SV = PV(0x1330f20f4c0) at 0x1330f2836a0
  REFCNT = 1
  FLAGS = (POK,IsCOW,pPOK)
  PV = 0x1330f3129f0 "sss"...\0
  CUR = 32
  LEN = 40
  COW_REFCNT = 1
Q: hex: 1330f312400, dec: 1318809838592
SV = PV(0x1330f20f4c0) at 0x1330f2836a0
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x1330f312400 "sss"...\0
  CUR = 32
  LEN = 34

Previously (5.32), there was consistency as expected: PV address was "real" RAM address; and simple fact of "packing to pointer" didn't change scalar' guts. Now, I see some weird huge ("virtual"?) addresses -- even though everything works (including, not shown above, accessing (or acquiring, same values) these pointers from C). Where such numbers come from, is this the new normal? Is difference in "Dump" output related to that, or totally another issue?

[dave_the_m]

You are seeing Copy-on-Write in action. In 5.32, the 's' x 32 expression is constant-folded at compile time, creating a hidden SV containing the 32-byte string. At run time this buffer is copied to $s. In 5.42, the copy is deferred: both $s and the hidden SV share the same PV buffer. When something happens to $s which looks like its buffer is going to be modified, then at that point the buffer is finally copied. pack 'p' is a wild-enough operation that perl assumes the worst, so does the copy before returning the (new) PC address.

The larger addresses are nothing to do with perl; they are just what the underlying OS and malloc() library supply.

Dave.

[Anonymous Monk]

Thanks for explanation. Looks like "'COW + p' leak by design now" to me, but maybe the case is too artificial for real life. I think pack has "You are responsible..." warning already.

use strict;
use Devel::Peek;
$Devel::Peek::pv_limit = 3;     # useless for UTF8
use warnings;
use feature 'say';

say $^V;

sub mem { say qx( tasklist /nh /fi "PID eq $$" ) =~ m[(\S+ K)$] }
mem();
{
    my $r = \ join '', 'a' .. 'z'; 
    $$r x= 1e7; 
    my $s = $$r;
    my $p = pack 'p', $s;
}
mem();
{
    my $r = \ join '', 'a' .. 'z'; 
    $$r x= 1e7; 
    my $s = $$r;
    my $p = pack 'p', $s;
}
mem();

__END__

v5.32.1
7,836 K
7,888 K
7,888 K

v5.42.0
8,036 K
261,972 K
515,880 K

[tonyc]

There were a few changes in that range relevant to the changes you're seeing:

• Strawberry Perl changed from doing an MSVCRT build of perl to UCRT, this is likely the cause of the change in pointer ranges (the addresses in both cases virtual addresses, like pretty much any pointer on a modern OS)
• Richard changed constant folding to allow constant folded strings to be marked Copy-on-Write in 06e421c559c
• I changed pack() to make SVs used for the pack "p" template non-CoW in more cases in 3d831e8998d, since we documented modifying SVs through the pointers pack() produces.

[syphilis]

Strawberry Perl changed from doing an MSVCRT build of perl to UCRT, this is likely the cause of the change in pointer ranges ...

I ran the given script on SP-5.38.2 (which still used MSVCRT) and got:

v5.38.2
SV = PV(0x1875c0cb100) at 0x1875c201748
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x1875c20cba0 "sss"...\0
  CUR = 32
  LEN = 34
Q: hex: 1875c20cba0, dec: 1680877865888
SV = PV(0x1875c0cb100) at 0x1875c201748
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x1875c20cba0 "sss"...\0
  CUR = 32
  LEN = 34

Apart from a missing "IsCow" flag, the output looks to me essentially the same as for SP-5.42.0.
This suggests to me that the switch to UCRT is not part of the explanation.

Cheers,
Rob

[ysth]

The larger addresses look to me like you just (inadvertently?) switched from a 32bit build to a 64bit build. It looks like Strawberry Perl does not list 32bit builds in recent perl versions.

[syphilis]

The larger addresses look to me like you just (inadvertently?) switched from a 32bit build to a 64bit build.

The OP's results are consistent with what I'm seeing on my 64-bit SP-5.32.1 and SP-5.42.0.
Also, the script's output on my 32-bit build of SP-5.32.1 includes the following (quite different) piece of output:

Missing argument in printf at try.pl line 9.
Missing argument in printf at try.pl line 9.
Q: hex: 0, dec: 0

Cheers,
Rob