2) Try running one of the tests which blocks, individually. If you can get it to happen this way, then run it in gdb and see what it's doing. (Or, attach to an already blocked one from 'make test'--this is assuming it's parrot that's actually blocking, and not t/harness.)
When run individually I get the same error. Complete freeze at what appears to be an arbitrary point.
Running gdb
0x080a7625 in Perl_sv_gets ()
I meant try running parrot in the debugger--Perl is probably hanging b/c it's waiting for parrot to exit. For instance, see if the following hangs, and if so run it in gdb:
./parrot --gc-debug -b t/op/arithmetics_4.pasm
This is where gdb freezes execution. CTL-C then frees it up to continue until the next one freezes.
The ctrl-C is probably killing the subprocess (parrot), which does imply that it's parrot that's hanging.
3) Try building from a clean checkout, and see if that shows the problem. If not, it's probably something you've changed and don't realize.
I have tried something a bit more drastic. Deleted the entire tree and downloaded it again (sorry about the bandwidth).
Yep, that's what I meant.
I have also tried strace and got the following.
Try this on parrot rather than Perl.
Doing a "ps ax" reveals the following (ignore the test number it keeps changing)
20802 pts/11 S 0:00 make test
21598 pts/11 S 0:00 perl t/harness --gc-debug --running-make-test -b t/op/00ff-dos.t t/op/00ff-unix.t t/op/arithmetics.t t/op/basic.t
21610 pts/11 S 0:00 perl -w t/op/arithmetics.t
21620 pts/11 S 0:00 ./parrot --gc-debug -b t/op/arithmetics_4.pasm
21621 pts/11 S 0:00 ./parrot --gc-debug -b t/op/arithmetics_4.pasm
21622 pts/11 S 0:00 ./parrot --gc-debug -b t/op/arithmetics_4.pasm
That does seem odd that it appears to be running the same test 3 times....
JEff
