Ticket #1060 (closed bug: fixed)

Opened 12 years ago

Last modified 12 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 12 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 12 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 12 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 12 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 12 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 12 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 12 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.