Обсуждение: Re: [COMMITTERS] pgsql: Refactor Perl test code
Michael Paquier <michael.paquier@gmail.com> writes:
> On Thu, Dec 3, 2015 at 8:38 AM, Tom Lane wrote:
>> Test Summary Report
>> -------------------
>> t/001_initdb.pl (Wstat: 6400 Tests: 8 Failed: 0)
>> Non-zero exit status: 25
>> Parse errors: Bad plan. You planned 14 tests but ran 8.
>> Files=1, Tests=8, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.08 cusr 0.01 csys = 0.11 CPU)
>> Result: FAIL
>> make[2]: *** [check] Error 1
>> make[2]: Leaving directory `/home/postgres/pgsql/src/bin/initdb'
>> make[1]: *** [check-initdb-recurse] Error 2
>> make[1]: Leaving directory `/home/postgres/pgsql/src/bin'
>> make: *** [check-world-src/bin-recurse] Error 2
>>
>> The buildfarm looks pretty unhappy too, though I've not checked to see if
>> it's exactly the same symptom everywhere.
> Or in more details:
> Undefined subroutine &TestLib::run called at
> /Users/mpaquier/git/postgres/src/bin/initdb/../../../src/test/perl/TestLib.pm
> line 146.
BTW, not the fault of this patch in particular, but this example points
up the complaint I've had right along about how opaque TAP test failures
are. How did you dig down to see that error message? Is it even possible
to diagnose such a failure from what the buildfarm logs?
regards, tom lane
On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > BTW, not the fault of this patch in particular, but this example points > up the complaint I've had right along about how opaque TAP test failures > are. How did you dig down to see that error message? Well, it showed up on my terminal... > Is it even possible to diagnose such a failure from what the buildfarm logs? Yes. If you look at TestLib.pm, stderr/stdout redirection is done in an INIT block, not BEGIN block, and INIT gets executed *after* the code is compiled. FWIW, I recall arguing in favor of adding this redirection logic in BEGIN so as we could get compilation errors directly in the log files... The reason why it is done this way is that it has been argued as well that we should not change the FS in the BEGIN block, but in the INIT block when TestLib.pm is loaded. -- Michael
Michael Paquier <michael.paquier@gmail.com> writes:
> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, not the fault of this patch in particular, but this example points
>> up the complaint I've had right along about how opaque TAP test failures
>> are. How did you dig down to see that error message?
> Well, it showed up on my terminal...
Not on mine, as per the extract I showed. Probably a Perl version
difference, but I don't think we can exactly write off RHEL6 as an
uninteresting obsolete distribution. (The Perl here is 5.10.1.)
regards, tom lane
On Thu, Dec 3, 2015 at 12:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> BTW, not the fault of this patch in particular, but this example points >>> up the complaint I've had right along about how opaque TAP test failures >>> are. How did you dig down to see that error message? > >> Well, it showed up on my terminal... > > Not on mine, as per the extract I showed. Probably a Perl version > difference, but I don't think we can exactly write off RHEL6 as an > uninteresting obsolete distribution. (The Perl here is 5.10.1.) Possible. On OSX 10.8: $ perl --version This is perl 5, version 16, subversion 2 (v5.16.2) built for darwin-thread-multi-2level (with 3 registered patches, see perl -V for more detail -- Michael
Tom Lane wrote: > Michael Paquier <michael.paquier@gmail.com> writes: > > On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> BTW, not the fault of this patch in particular, but this example points > >> up the complaint I've had right along about how opaque TAP test failures > >> are. How did you dig down to see that error message? > > > Well, it showed up on my terminal... > > Not on mine, as per the extract I showed. Probably a Perl version > difference, but I don't think we can exactly write off RHEL6 as an > uninteresting obsolete distribution. (The Perl here is 5.10.1.) Hmm, maybe a selinux policy or something like that is preventing some system call from working, and this causes a Perl call to fail which we may be failing to report; for instance we haveopen(ORIG_STDOUT, ">&STDOUT"); in TestLib.pm's INIT block, without an "or die" which would let us know that it failed. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Michael Paquier <michael.paquier@gmail.com> writes:
>>> Well, it showed up on my terminal...
>> Not on mine, as per the extract I showed. Probably a Perl version
>> difference, but I don't think we can exactly write off RHEL6 as an
>> uninteresting obsolete distribution. (The Perl here is 5.10.1.)
> Hmm, maybe a selinux policy or something like that is preventing some
> system call from working,
Good thought, but overcomplicated. After some quality time with strace,
I find that the
Undefined subroutine &TestLib::run called at /home/postgres/pgsql/src/bin/initdb
/../../../src/test/perl/TestLib.pm line 146.
error message does indeed appear, but it's printed only into
src/bin/initdb/tmp_check/log/regress_log_001_initdb
It appears that the reason this happens is that the child perl process
(of the two that are active in this area of the trace) decides at one
point along the line to redirect its own stdout and stderr into that
file, disconnecting them from the pipes leading to the parent process.
So when that process prints "Undefined subroutine" to its stderr, that
is where it goes.
I suppose that the redirection is a result of this bit in TestLib.pm:
# Hijack STDOUT and STDERR to the log fileopen(ORIG_STDOUT, ">&STDOUT");open(ORIG_STDERR, ">&STDERR");open(STDOUT,
">&TESTLOG");open(STDERR, ">&TESTLOG");
so the question from my end is not so much why it doesn't work for me
as how it could possibly work for you. Could the newer Perl version
be detecting the undefined-subroutine error before it executes the
file's INIT stanza, rather than after? Or maybe the "tie" stuff
happening just below this acts differently in more modern Perls?
regards, tom lane