Обсуждение: Perl 5.18 breaks pl/perl regression tests?

Buildfarm member anchovy has been failing the pl/perl regression tests
for the last 11 days.  Since configure is helpful enough to print the
version number of the Perl it finds, we can see that anchovy's Perl
version was 5.16.3 in its last successful run, but it's been using
5.18.0 in all the failed runs.  The output differences are:

*** /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/expected/plperl.out    Thu May 23 00:23:22 2013
--- /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/results/plperl.out    Thu May 23 00:36:31 2013
***************
*** 627,633 **** CONTEXT:  PL/Perl anonymous code block -- check that eval is allowed and eval'd restricted ops are
caughtDO $$ eval q{chdir '.'}; warn "Caught: $@"; $$ LANGUAGE plperl;
 
! WARNING:  Caught: 'chdir' trapped by operation mask at line 2. CONTEXT:  PL/Perl anonymous code block -- check that
compilingdo (dofile opcode) is allowed -- but that executing it for a file not already loaded (via require) dies
 
--- 627,633 ---- CONTEXT:  PL/Perl anonymous code block -- check that eval is allowed and eval'd restricted ops are
caughtDO $$ eval q{chdir '.'}; warn "Caught: $@"; $$ LANGUAGE plperl;
 
! WARNING:  Caught: 'chdir' trapped by operation mask at line 1. CONTEXT:  PL/Perl anonymous code block -- check that
compilingdo (dofile opcode) is allowed -- but that executing it for a file not already loaded (via require) dies
 

======================================================================

*** /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/expected/plperl_init.out    Thu May 23 00:23:22 2013
--- /home/pgfarm/build/HEAD/pgsql.702/src/pl/plperl/results/plperl_init.out    Thu May 23 00:36:32 2013
***************
*** 9,14 **** (1 row)  DO $$ warn 42 $$ language plperl;
! ERROR:  'system' trapped by operation mask at line 2. CONTEXT:  while executing plperl.on_plperl_init PL/Perl
anonymouscode block
 
--- 9,14 ---- (1 row)  DO $$ warn 42 $$ language plperl;
! ERROR:  'system' trapped by operation mask at line 1. CONTEXT:  while executing plperl.on_plperl_init PL/Perl
anonymouscode block
 

Now, maybe I'm missing something, but the actual outputs look saner than
the expected outputs --- surely, by any reasonable counting method,
those error locations are indeed in line 1 of the plperl code blocks.
So why do we have "line 2" in the expected output, and why are all the
other machines happy with that?

Can anyone else replicate this change of behavior?  Is there anything
about it in the Perl release notes?

It looks quite a bit like somebody's fixed a line-counting bug inside
Perl, which may mean that we'll have to maintain two expected-output
files or else remove these particular test cases.  Which would be
annoying.
        regards, tom lane

Tom Lane wrote:

> It looks quite a bit like somebody's fixed a line-counting bug inside
> Perl, which may mean that we'll have to maintain two expected-output
> files or else remove these particular test cases.  Which would be
> annoying.

Maybe we can set a $SIG{__WARN__} routine instead, which would re-print
the warning appending a \n, to supress the line count.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 2013-06-03 06:55, Michael Paquier wrote:
> Just by having a look at the release notes of Perl, there are still 
> nothing describing changes between 1.6.3 and 1.8.0:
> http://perldoc.perl.org/index-history.html
>
That page is not updated, it seems. In this list

https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod

is mentioned "Line numbers at the end of a string eval are no longer off 
by one. [perl #114658]"

Kaare Rasmussen <kaare@jasonic.dk> writes:
> That page is not updated, it seems. In this list
> https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod
> is mentioned "Line numbers at the end of a string eval are no longer off 
> by one. [perl #114658]"

Hah.  That leads to
http://perl5.git.perl.org/perl.git/commitdiff/451f421
in which it's said "What happens is that eval tacks "\n;" on to the end
of the string if it does not already end with a semicolon."

So we could likely hide the cross-version difference in behavior by
adjusting these two test cases to include a semicolon in the eval'd
string.
        regards, tom lane

On Jun 3, 2013, at 7:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Hah.  That leads to
> http://perl5.git.perl.org/perl.git/commitdiff/451f421
> in which it's said "What happens is that eval tacks "\n;" on to the end
> of the string if it does not already end with a semicolon."
> 
> So we could likely hide the cross-version difference in behavior by
> adjusting these two test cases to include a semicolon in the eval'd
> string.

And a comment, since that is, shall we say, rather obscure.

David