New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ext/GDBM_File/t/gdbm.t: intermittent failures #16753
Comments
From @jkeenanOver the last few days I've started to get failures in When I run 'make test_harness', I tend to get these: ##### ../ext/GDBM_File/t/gdbm.t (Wstat: When I run only ext/GDBM_File/t/gdbm.t through 't/harness', I get a PASS: ##### When I run it through the harness along with test files from *other ##### But when I run it through the harness along with *the other test file in ##### # Failed test at ../../t/lib/dbmt_common.pl line 105. # Failed test at ../../t/lib/dbmt_common.pl line 106. # Failed test at ../../t/lib/dbmt_common.pl line 115. # Failed test at ../../t/lib/dbmt_common.pl line 118. # Failed test at ../../t/lib/dbmt_common.pl line 130. Test Summary Report ../ext/GDBM_File/t/gdbm.t (Wstat: 1536 Tests: 134 Failed: 6) I suspect that this is related to: ##### Add more parallelism to t/harness But the fix I tried for ext/File-Find/t in commit Thank you very much. |
From @jkeenanOn Sat, 17 Nov 2018 22:19:41 GMT, jkeenan@pobox.com wrote:
Here is a partial diagnosis of the problem (which is likely to apply to the re-opened https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133658 as well): When you call: ##### ... the list of test files gets picked up by t/harness here: ##### (Try out the t-harness-debugging.diff attachment to see this more easily.) By being assigned to @tests -- the list of tests that ultimately gets passed to TAP::Harness->runtests -- here, the files listed on the command-line (or derived via shell expansion) avoid getting examined for belonging to the list of directories -- %serials -- whose individual test files should *not* be run in parallel. That examination only takes place deep inside the 'else' block following the 'if' block cited above. ##### This 'else' block is (I think) what gets exercised when you say 'make test_harness'. That would explain why certain failures do not show up during 'make test_harness' and do not show up in smoke test reports when the testing rig is configured -- as most but not all are -- to run t/harness but not t/TEST.pl. This logic for separate handling of non-parallelizable directories during 'make test_harness' was added by Karl, mostly in commit 9b0adf1, in July of this year. I think something like that needs to be added to the 'if' block as well. -- |
From @jkeenant-harness-debugging.diffdiff --git a/t/harness b/t/harness
index da5c017695..bb374e14d2 100644
--- a/t/harness
+++ b/t/harness
@@ -91,6 +91,7 @@ if ($ENV{HARNESS_OPTIONS}) {
}
if (@ARGV) {
+print STDERR "XXX: There are files in \@ARGV\n";
# If you want these run in speed order, just use prove
if ($^O eq 'MSWin32') {
@tests = map(glob($_),@ARGV);
@@ -98,10 +99,12 @@ if (@ARGV) {
else {
@tests = @ARGV;
}
+print STDERR "XXX1: \@tests: @tests\n";
# This is a hack to force config_heavy.pl to be loaded, before the
# prep work for running a test changes directory.
1 if $Config{d_fork};
} else {
+print STDERR "YYY: \n";
# Ideally we'd get somewhere close to Tux's Oslo rules
# my $rules = {
# par => [
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Sat, 17 Nov 2018 23:23:40 GMT, jkeenan wrote:
Working on this in branch 'jkeenan/133664-harness'. Not ready for prime time. -- |
From @iabynOn Sat, Nov 17, 2018 at 06:36:57PM -0800, James E Keenan via RT wrote:
I've fixed GDBM with this: commit d33f9fb ext/GDBM_File/t/fatal.t: support parallel testing M ext/GDBM_File/t/fatal.t -- |
From @jkeenanOn Mon, 19 Nov 2018 13:59:12 GMT, davem wrote:
I'll take this ticket for the purpose of monitoring smoke test results and close it in several days if things look good. Thank you very much. -- |
From @jkeenanOn Mon, 19 Nov 2018 23:17:40 GMT, jkeenan wrote:
Though we're still experiencing test failures in ext/GDBM_File/t on certain platforms, those failures appear to be due to problems with the (newer) versions of gdbm thereupon. So this ticket is closable. Thank you very much. -- |
@jkeenan - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.30.0, this and 160 other issues have been Perl 5.30.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#133664 (status was 'resolved')
Searchable as RT133664$
The text was updated successfully, but these errors were encountered: