Skip to content
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

(harness) test fails when called through make, succeeds otherwise #341

Closed
p6rt opened this issue Sep 26, 2008 · 10 comments
Closed

(harness) test fails when called through make, succeeds otherwise #341

p6rt opened this issue Sep 26, 2008 · 10 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Sep 26, 2008

Migrated from rt.perl.org#59372 (status was 'resolved')

Searchable as RT59372$

@p6rt
Copy link
Author

p6rt commented Sep 26, 2008

From @moritz

in r31436 the test t/spec/S29-conversions/ord_and_chr.t fails on my
computer when called through make (ie 'make spectest_regression' or
'make t/spec/S29-conversions/ord_and_chr.t', but succeeds if the
corresponding .rakudo file is called manually, or though
tools/test_summary.pl.

output through make​:

$ TEST_JOBS=1 make t/spec/S29-conversions/ord_and_chr.t
t/spec/S29-conversions/ord_and_chr...........
1..240
ok 1 - ord() works for \32 == ' '
ok 2 - chr() works for \32 == ' '
...
ok 172 - chr() works for \117 == 'u'
ok 173 - ord() works for \118 == 'v'
Failed 67/240 subtests

Test Summary Report


t/spec/S29-conversions/ord_and_chr.rakudo (Wstat​: 11 Tests​: 173 Failed​: 0)
  Parse errors​: Bad plan. You planned 240 tests but ran 173.
Files=1, Tests=173, 3 wallclock secs ( 0.03 usr 0.00 sys + 2.55 cusr
0.04 csys = 2.62 CPU)
Result​: FAIL

When executed directly it passes all 240 tests (minus two skipped
tests), and everything is fine.

This is on Debian GNU/Linux "Etch", i386 32bit.

Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

@p6rt
Copy link
Author

p6rt commented Sep 26, 2008

From @moritz

A few more details​:

This happens with both the system perl (5.8.8) and a vanilla 5.10.0
perl, and is also reproducible from a clean 'svn export' copy, and
without ccache (which I usually use for compiling parrot).

On another 32bit Debian system (with Testing this time) everything works
fine.

Still no clue what's going on...

@p6rt
Copy link
Author

p6rt commented Sep 26, 2008

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Sep 27, 2008

From @moritz

On Fri Sep 26 09​:05​:32 2008, moritz@​casella.verplant.org wrote​:

in r31436 the test t/spec/S29-conversions/ord_and_chr.t fails on my
computer when called through make (ie 'make spectest_regression' or
'make t/spec/S29-conversions/ord_and_chr.t', but succeeds if the
corresponding .rakudo file is called manually, or though
tools/test_summary.pl.

weird things, today all is fine, no failures any more. Marking this as
rejected since I can't reproduce it anymore.

@p6rt
Copy link
Author

p6rt commented Sep 27, 2008

@moritz - Status changed from 'open' to 'rejected'

@p6rt
Copy link
Author

p6rt commented Sep 27, 2008

From @pmichaud

On Fri, Sep 26, 2008 at 09​:05​:32AM -0700, Moritz Lenz wrote​:

in r31436 the test t/spec/S29-conversions/ord_and_chr.t fails on my
computer when called through make (ie 'make spectest_regression' or
'make t/spec/S29-conversions/ord_and_chr.t', but succeeds if the
corresponding .rakudo file is called manually, or though
tools/test_summary.pl.

This has to be a problem with the test harness or Parrot somehow --
we've noted many times in the past that running things from the
harness sometimes causes things to fail that otherwise succeed.

At this point I'm not sure if this ticket belongs in the perl6
RT queue or the parrot RT queue. There's not much that Rakudo
can do to resolve the issue, so I'm thinking we may need to move
it to the Parrot queue.

Pm

@p6rt
Copy link
Author

p6rt commented Sep 27, 2008

From @moritz

re-opened because others (rindolf) experienced the same error.

@p6rt
Copy link
Author

p6rt commented Sep 27, 2008

@moritz - Status changed from 'rejected' to 'open'

@p6rt
Copy link
Author

p6rt commented Feb 2, 2009

From @moritz

We haven't seen a manifestation of that bug for quite some time; hope
it's gone...

@p6rt
Copy link
Author

p6rt commented Feb 2, 2009

@moritz - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Feb 2, 2009
@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant