Tracking down the source of a new 5.10 warning

[mpeters]

I'm trying to run an existing application on 5.10 for the first time (5.10.0 for right now) and am getting a warning that is not making it easy for me to track down. Any help from the lazy web would be appreciated.

It goes like this:

      Variable "$x" is not available at (re_eval 1070) line 1.

I'm assuming this is pretty deep inside some dependency I'm using (of which my application probably has an old version which doesn't play nicely with 5.10). Google is no help here as it returns a lot of CPAN testers results with the same warning for various modules (http://www.mail-archive.com/[e-mail]/msg652326.html, http://trouchelle.com/perl/ppmrepview.pl?id=33577&v=10).

My normal trick of using

      $SIG{__WARN__} = \*Carp::cluck;

to get a nice stack trace of where the warning is coming from is not actually giving me a stack trace. Anyone have any extra ideas?

[ikegami]

Subs only capture the vars they think they need. They get it wrong in the case sub { eval '$x' }.

In older versions of Perl, the error was silent.

$ perl -wle'
    sub make {
        my ($x) = @_;
        return sub {
            eval q{$x};
        };
    }

    print make(123)->()
'
Use of uninitialized value in print at -e line 9.

In newer versions of Perl, the error still exists, but a warning issued.

$ perl -wle'
    sub make {
        my ($x) = @_;
        return sub {
            eval q{$x};
        };
    }

    print make(123)->()
'
Variable "$x" is not available at (eval 1) line 2.
Use of uninitialized value in print at -e line 9.

The solution is to add a reference to the variable that needs to be captured inside of the anon sub.

$ perl -wle'
    sub make {
        my ($x) = @_;
        return sub {
            $x if 0;      # <--- added
            eval q{$x};
        };
    }

    print make(123)->()
'
123

[BrowserUk]

I knew I'd seen this somewhere. Did you see this from perlintern ?

The flag SVf_PADSTALE is cleared on lexicals each time the my() is executed, and set on scope exit. This allows the 'Variable $x is not available' warning to be generated in evals, such as

I'm not sure what that means, but there is an example following the above quote that, in conjunction with your knowledge of what you are doing, may help you narrow your search.

To track it further, you might try Devel::Trace and pipe the output through grep looking for '$x':

C:\test>perl -d:Trace -E" { my $x; sub f{ eval '$x'; } } f()"
>> [0] -e                            :    1:  { my $x; sub f{ eval '$x
+'; } } f()
>> [0] -e                            :    1:  { my $x; sub f{ eval '$x
+'; } } f()
>> [0] -e                            :    1:  { my $x; sub f{ eval '$x
+'; } } f()
>> [0] -e                            :    1:  { my $x; sub f{ eval '$x
+'; } } f()
>> [0] (eval 2)[-e:1]                :    1: $x

I can't get their example to produce the error, but by filtering the output from D::T you ought to be able to locate the source fairly easily.

[Your Mother]

Try Carp::Always?

[diotalevi]

You say your trick of $SIG{__WARN__} = ... isn't working. Perhaps the warning occurs prior to your assignment. Try executing that assignment very early, perhaps in a BEGIN block.

[mpeters]

Ok, I've tracked down the problem to Regexp::Common. I've changed places in the code that used to have:

use Regexp::Common;

to instead

use Regexp::Common qw(number);

Which should actually reduce memory usage as well. And the reason that my Carp/$SIG{__WARN__} trick didn't work was because this was a place in the test suite that generated code and executed it in another process (with a fresh new perl). Thanks for all the suggestions.

[diotalevi]

Ah. If you'd wanted to affect another perl, you could use the environment variable PERL5OPT. I've occasionally run with it set to things like -MCarp::Always to convert all my programs to use verbose warnings.1