Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code
Alvaro Herrera writes: > Tom Lane wrote: >> Michael Paquier 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 file open(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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code
Tom Lane wrote: > Michael Paquier writes: > > On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane 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 have open(ORIG_STDOUT, ">&STDOUT"); in TestLib.pm's INIT block, without an "or die" which would let us know that it failed. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code
On Thu, Dec 3, 2015 at 12:50 PM, Tom Lane wrote: > Michael Paquier writes: >> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code
Michael Paquier writes: > On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code
On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code
Michael Paquier 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers