in reply to Interpreter eval counter out of bounds

"Will not stay shared" is a warning that indicates one made the error of nesting nesting named subs. Specifically, it is issued when an inner named sub captures vars from the outer sub. 

$ perl -we'sub outer { my $x; sub inner { $x } }'
Variable "$x" will not stay shared at -e line 1.

[download]

Don't nest named subs. It's not like inner is private to outer.

"Global symbol requires explicit package name" is an error detected by "use strict;". 

$ perl -we'use strict; $i'
Global symbol "$i" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

[download]

Loading Carp::Always might be a simple way of getting useful diagnostics.

I notice the eval counter (if such a thing exists) in each case seems to be very close to 10**9.

109 is not a particularly interesting number to computers. If it was 22n or 22n-1 (e.g. 28, 215, 216, 231, 232, etc), then it would get my attention.

(Why oh why do you generate and execute so many code snippets!)

Replies are listed 'Best First'.
Re^2: Interpreter eval counter out of bounds
by Jeppe (Monk) on Jan 29, 2011 at 10:19 UTC
    We are well aware that we should not nest nested named subs. We don't do that. And the code works normally. It's just that all of a sudden the code stops working (well, the perl interpreter stops working it seems), and the eval counter is at roughly the same position each time the code stops working. Given that the code is non-deterministic, what portion of the code that fails is random.

    Some of the code snippets that increase the eval counter are well justified, some are perhaps not. But currently, the non-deterministic application is crashing on a regular basis, and the only common factor we've found is that the counter is around 999970000. It seems like a major coincidence.

[reply]

      I'm currently running the following code snippet:

      perl -Mstrict -wle "my@r;$|++;while($_++<$ARGV[0]){eval sprintf q{my$s
+elf=\%s;push @r,sub{ $self }},$_,$_; if(!($_%100000)){printf qq(%010d
+\r),$_;@r=()}}" 1000000000

      [download]

      but I've only reached 479_000_000 iterations so far, doing about 10_000 evaluations per second. If that doesn't turn up any errors, maybe we should work on code that pumps up the counter more quickly to 999_000_000 string evals and then slowly iterates there.

      I think what would help was some more information about the nature of the code you're evaluating. Is my code anywhere near, creating closures? Or don't closures come into play with your code at all?

      Update: The code has run through (on Strawberry Perl 5.12) without a hitch.

      Update: Running the code for somewhat longer actually produces the error on Strawberry 5.12 for me too:

      Expect crash1073700000
Expect crashGlobal symbol "$abc" requires explicit package name at (ev
+al 1073741769) line 1.

      [download]
[reply]
[d/l]
[select]
        Success! I've recreated the bug! 
        #!/opt/perl/bin/perl

use strict;
use warnings;

my $count = 0;

until ($@) {
  $count++;
  eval 'my $abc = 1; $abc++; ';
  unless ($count % 100000) {
    print $count . $/;
    print q(Expect crash) if $count > 999977609;
  }
}

print $@;
        This produced:
        ....
        1073700000 - Expect crash
        Global symbol "$abc" requires explicit package name at (eval 1073741770) line 1.
        So, there is a limit. This was run on perl 5.12.2, though the crashing system runs perl 5.8.9.
[reply]

        Not enough iterations. After almost 9 hours, got: 

        1073741811: Global symbol "$abc" requires explicit package name at (ev
+al 1073741811) line 1.

        [download]

        repeated 5 times for sequential numbers after 1073741811 from: 

        #!/usr/bin/perl -w
use strict;

my $count= 0;
my $fail= 0;
$|= 1;
while(  1  ) {
    if(  0 == ++$count % 100_000  &&  -t STDOUT  ) {
        print "\r$count  ";
    }
    if(  ! eval 'my $abc = 1; $abc++; 1'  ) {
        print "\n$count: $@\n";
        exit
            if  5 < ++$fail;
    }
}

        [download]

        under 

        This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi

        [download]

        - tye        

[reply]
[d/l]
[select]
      One thing that could support the theory due to interpreter corruption is that both errors are related to lexical variables. It could be a problem with the pad of the function doing the eval.
[reply]

In Section Seekers of Perl Wisdom