Hi,
I've been looking into a failure of F<t/dynoplibs/myops.t> on Windows,
but I don't think the problem is limited to that platform.
$ prove t\dynoplibs\myops.t
t\dynoplibs\myops......5/10
t\dynoplibs\myops......6/10 # Failed test 'three alarm'
# at t\dynoplibs\myops.t line 118.
# Exited with error code: 255
# Received:
# alarm1
# alarm2
# alarm3
#
# Expected:
# /alarm1
# alarm2
# alarm3/
#
The test output is good, but the error code is 255. Actually, the test
exits with an access violation.
After stepping through things a couple of times with a debugger I think
the cause for this is that through the final DOD run (Parrot_exit ->
Parrot_really_destroy -> Parrot_do_dod_run) the scheduler is destroyed
*before* the last task.
When the task is finally destroyed, the scheduler is already 0xdeadbeef.
Here's the final stack trace.
Parrot_cx_delete_task
Parrot_Timer_destroy
Parrot_dod_free_pmc
Parrot_dod_sweep
Parrot_dod_ms_run
Parrot_do_dod_run
Parrot_really_destroy
Parrot_exit
At this line in Parrot_cx_delete_task.
VTABLE_delete_keyed_int(interp, interp->scheduler, tid);
That's as far as I got. I don't know enough about the DOD details to
make a good guess on the cause. Maybe both scheduler and task are
determined to be not-reachable, but the destruction sequence is not ordered?
Ron
