From @lucs

It fails when rakudo has not yet been installed. Perhaps the makefile
should invoke the tests with the -Ilib flag, or the file itself should
have a "use lib 'lib';" line?

From ungrim97@hotmail.com

I have picked this up. But don't currently have RT permissions

From ungrim97@hotmail.com

rakudo/rakudo#609

From ungrim97@hotmail.com

On Wed Dec 02 05​:22​:19 2015, scullucs wrote​:

It fails when rakudo has not yet been installed. Perhaps the makefile
should invoke the tests with the -Ilib flag, or the file itself should
have a "use lib 'lib';" line?

Was able to replicate once but no cannot.....

From @lucs

Gah! I meant t/16-rt125408.t, sorry about that (but the issue
remains).

From ungrim97@hotmail.com

I have been completely unable to replicate any issues with make test on a fresh vm.

Steps​:

git clone http://github.com/rakudo/rakudo
cd rakudo
perl ./Configure.pl --gen-moar --gen-nqp --backends=moar --prefix=$HOME
make
make test

/data0/www/adcourier.broadbean/perl5/perlbrew/perls/perl-5.18.2/bin/perl t/harness --moar t/01-sanity t/04-nativecall
t/01-sanity/01-literals.t ............ ok
t/01-sanity/02-op-math.t ............. ok
t/01-sanity/03-op-logic.t ............ ok
t/01-sanity/04-op-cmp.t .............. ok
t/01-sanity/05-var.t ................. ok
t/01-sanity/06-op-inplace.t .......... ok
t/01-sanity/07-op-string.t ........... ok
t/01-sanity/08-var-array.t ........... ok
t/01-sanity/09-end-blocks.t .......... ok
t/01-sanity/10-regex.t ............... ok
t/01-sanity/11-tap.t ................. ok
t/01-sanity/12-counter.t ............. ok
t/01-sanity/13-equal.t ............... ok
t/01-sanity/14-if.t .................. ok
t/01-sanity/15-sub.t ................. ok
t/01-sanity/16-eqv.t ................. ok
t/01-sanity/17-isa.t ................. ok
t/01-sanity/18-simple-multisubs.t .... ok
t/01-sanity/19-say.t ................. ok
t/01-sanity/20-defined.t ............. ok
t/01-sanity/21-try.t ................. ok
t/01-sanity/52-parse-include-spec.t .. ok
t/01-sanity/53-transpose.t ........... ok
t/01-sanity/55-use-trace.t ........... ok
t/01-sanity/99-test-basic.t .......... ok
t/04-nativecall/01-argless.t ......... ok
t/04-nativecall/02-simple-args.t ..... ok
t/04-nativecall/03-simple-returns.t .. ok
t/04-nativecall/04-pointers.t ........ ok
t/04-nativecall/05-arrays.t .......... ok
t/04-nativecall/06-struct.t .......... ok
t/04-nativecall/07-writebarrier.t .... ok
t/04-nativecall/08-callbacks.t ....... ok
t/04-nativecall/09-nativecast.t ...... ok
t/04-nativecall/10-cglobals.t ........ ok
t/04-nativecall/11-cpp.t ............. ok
t/04-nativecall/12-sizeof.t .......... ok
t/04-nativecall/13-cpp-mangling.t .... ok
t/04-nativecall/13-union.t ........... ok
t/04-nativecall/14-rw-attrs.t ........ ok
t/04-nativecall/15-rw-args.t ......... ok
t/04-nativecall/16-rt125408.t ........ ok
t/04-nativecall/16-rt125729.t ........ ok
All tests successful.
Files=43, Tests=544, 110 wallclock secs ( 0.14 usr 0.11 sys + 105.51 cusr 3.86 csys = 109.62 CPU)
Result​: PASS

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

From @lucs

After checking out and cleanly building all rakudo commits going back to one that I'm certain precedes the one where I got the error, it turns out that only t/04-nativecall/11-cpp.t fails (in the past), and never t/16-rt125408.t (I think that explains my error in the ticket title​: I copypasted the wrong file name from the screen where I had seen the failure.)

Yet I'm quite certain that the fail was occuring on t/16-rt125408.t, during a "make test" run. At the moment it occurred, I was nuking my whole rakudo directory and starting from scratch at each build (to get a feel for things I guess). Now that I look more closely, I understand that such builds from scratch check out fresh copies of nqp and MoarVM. The latter had a few commits done around the time I was building, so maybe its an unfortunate combination of rakudo+nqp+MoarVM that caused the now irreproducible error.

I won't be trying out different combinations of rakudo+nqp+MoarVM commits, so I'm closing the ticket, and it will remain a mystery to me as to why it ever happened.

In conclusion, I'll try to remember that a bit of patience on my part would probably have sufficed to avoid the false alarm.

Thanks for looking into it!

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