Thread: 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
On Mon, Jun 3, 2013 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
--
Michael
Can anyone else replicate this change of behavior?
Yes. I could reproduce that on an Archlinux box after updating to perl 1.8.0. hamster might also fail with the same error, I just updated its perl from 1.6.3 to 1.8.0.
Is there anything about it in the Perl release notes?
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:
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.
+1 for adding some new expected output files.
Michael
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