Re: The memory for variables is not allocated for DB::DB reentrance

[KES]

Seems I found workaround:

package DB;

use strict;
use warnings;

our $level =  0;

sub test {
        my $x =  0;
        $x += $level;
        print ">LEVEL: $level; VALUE: $x", \$x,"\n";
        local $level =  $level +1;
        $^D |=  (1<<30)   if $level < 3;
        main::t0();
        print "<LEVEL: $level; VALUE: $x", \$x,"\n";
        return;
}

sub DB {
        test();
}

1;


$ perl -I. -d:DB t3.pl
>LEVEL: 0; VALUE: 0SCALAR(0xd05008)
>LEVEL: 1; VALUE: 1SCALAR(0xcfb6c8)
>LEVEL: 2; VALUE: 2SCALAR(0xd29ea8)
<LEVEL: 3; VALUE: 2SCALAR(0xd29ea8)
<LEVEL: 2; VALUE: 1SCALAR(0xcfb6c8)
<LEVEL: 1; VALUE: 0SCALAR(0xd05008)


01.09.2016, 20:19, "KES" <kes-...@yandex.ru>:
> Hi, I am trying to write perl debugger which will allow to debug debugger 
> commands. So I play with '$^D |= (1<<30)' much.
> This allows me to reenter DB::DB and do my staff.
>
> Here is minified example which shows that memory for '$x' variable is not 
> allocated again for DB::DB reentrance.
>
> $ cat t3.pl
> #!/usr/bin/env perl
>
> sub t0 {}
>
> 1;
>
> $ cat Devel/DB.pm
> package DB;
>
> use strict;
> use warnings;
>
> our $level = 0;
>
> sub DB {
>         my $x = 0;
>         $x += $level;
>         print ">LEVEL: $level; VALUE: $x", \$x,"\n";
>         local $level = $level +1;
>         $^D |= (1<<30) if $level < 3;
>         main::t0();
>         print "<LEVEL: $level; VALUE: $x", \$x,"\n";
>         return;
> }
>
> 1;
>
> $ perl -I. -d:DB t3.pl
>> LEVEL: 0; VALUE: 0SCALAR(0x1ceb008)
>> LEVEL: 1; VALUE: 1SCALAR(0x1ceb008)
>> LEVEL: 2; VALUE: 2SCALAR(0x1ceb008)
>
> <LEVEL: 3; VALUE: 2SCALAR(0x1ceb008)
> Use of uninitialized value $x in concatenation (.) or string at Devel/DB.pm 
> line 15.
> <LEVEL: 2; VALUE: SCALAR(0x1ceb008)
> Use of uninitialized value $x in concatenation (.) or string at Devel/DB.pm 
> line 15.
> <LEVEL: 1; VALUE: SCALAR(0x1ceb008)
>
> Here we see that for each reentrance the address of $x pointer same place.
>
> mst guess: that my weird reentrancy means the 'sub DB' pad stack isn't 
> getting pushed to allocate a new pad
>
> Is this a bug?
> May someone advice workaround for this until this will be fixed?
> Thanks.