Ticket #1060 (closed bug: fixed)

Opened 5 years ago

Last modified 5 years ago

Inconsistent test failures in t/op/annotate.t

Reported by: ash.gti Owned by:
Priority: normal Milestone:
Component: testing Version: trunk
Severity: medium Keywords: intermittent test failure
Cc: Language:
Patch status: Platform: darwin


After updating to the most recent trunk and running make test I seem to be getting random failures on t/op/annotate.t. It is returning:

	Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 16-33
	Failed 18/33 tests, 45.45% okay
Failed Test     Stat Wstat Total Fail  List of Failed
t/op/annotate.t    0    11    33   36  16-33
Failed 1/1 test scripts. 18/33 subtests failed.
Files=1, Tests=33,  1 wallclock secs ( 0.05 cusr +  0.04 csys =  0.09 CPU)
Failed 1/1 test programs. 18/33 subtests failed.
make: *** [test_pbc_annotation_persistence] Error 255

But it happens very inconsistently. Occasionally it will pass, other times it dies right there. Test 16 in the source code is on line 116 in t/op/annotate.t

Change History

Changed 5 years ago by ash.gti

I double checked this with release 1.6.0 and it does it in 1.6.0 but less frequently. For reference I just ran make test 20 times with the trunk and 12 times it failed to pass the above test, the rest it passed. With the 1.6.0 tag release I ran it 20 times and it failed 8 of the times.

Again, it seems rather in consistent, I have no idea how to track down the cause of this bug or I'd try to give more information.

Changed 5 years ago by dukeleto

If you could run the test in gdb and show a backtrace of when it fails, that would be awesome:

$ gdb ./parrot
gdb> b Parrot_break
gdb> run t/op/annotate.t

To get a full backtrace you can do "bt full"

Changed 5 years ago by dukeleto

  • keywords intermittent test failure added
  • summary changed from Inconsistant test failures in t/op/annotate.t to Inconsistent test failures in t/op/annotate.t

Changed 5 years ago by ash.gti

Results of the backtrace from gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001001187d2 in Parrot_get_sub_pmc_from_subclass (interp=0x101508f90, subclass=0x10182ff60) at src/sub.c:618
618	    if (VTABLE_isa(interp, subclass, CONST_STRING(interp, "Sub"))) {
(gdb) bt
#0  0x00000001001187d2 in Parrot_get_sub_pmc_from_subclass (interp=0x101508f90, subclass=0x10182ff60) at src/sub.c:618
#1  0x00000001001d60ac in Parrot_Exception_nci_backtrace (interp=0x101508f90, pmc=0x1018a87c0) at exception.pmc:776
#2  0x00000001001e8298 in Parrot_NCI_invoke (interp=0x101508f90, pmc=0x1018a87c0, next=0x1019108b0) at nci.pmc:342
#3  0x000000010002f5cc in Parrot_callmethodcc_p_sc (cur_opcode=0x101910898, interp=0x101508f90) at object.ops:77
#4  0x000000010011199b in runops_slow_core (interp=0x101508f90, runcore=0x10151ca90, pc=0x101910898) at src/runcore/cores.c:843
#5  0x000000010011005c in runops_int (interp=0x101508f90, offset=0) at src/runcore/main.c:549
#6  0x00000001000b6282 in runops (interp=0x101508f90, offs=0) at src/call/ops.c:119
#7  0x00000001000b6651 in runops_args (interp=0x101508f90, sub=0x1018cd9f0, obj=0x1018abbe0, meth_unused=0x0, sig=0x1002dfe42 "vP", ap=0x7fff5fbff660) at src/call/ops.c:269
#8  0x00000001000b74f8 in Parrot_runops_fromc_args (interp=0x101508f90, sub=0x1018cd9f0, sig=0x1002dfe42 "vP") at src/call/ops.c:338
#9  0x0000000100092b26 in Parrot_runcode (interp=0x101508f90, argc=1, argv=0x7fff5fbff8b0) at src/embed.c:827
#10 0x00000001002b744c in imcc_run_pbc (interp=0x101508f90, obj_file=0, output_file=0x0, argc=1, argv=0x7fff5fbff8b0) at compilers/imcc/main.c:792
#11 0x00000001002b8281 in imcc_run (interp=0x101508f90, sourcefile=0x7fff5fbff9f2 "t/op/annotate.t", argc=1, argv=0x7fff5fbff8b0) at compilers/imcc/main.c:1075
#12 0x00000001000010e4 in main (argc=1, argv=0x7fff5fbff8b0) at src/main.c:60

Hope that helps

Changed 5 years ago by NotFound

The problem may be the use of new 'ParrotInterpreter' to get an interpreter pmc to get annotations from. I change that in r41444 to use getinterp instead. I hope that will fix the problem.

Changed 5 years ago by ash.gti

After upgrade to a version past r41444 I have not seen this issue again. I had a script run that test 30 times in a row and I haven't seen the failure again. I think the issue might be gone now thanks to NotFound's changes in r41444

Changed 5 years ago by NotFound

  • status changed from new to closed
  • resolution set to fixed

Thanks. Closing ticket.

Note: See TracTickets for help on using tickets.