On 20/10/11 18:46, Stefan Seifert wrote:
On Thursday 20 October 2011 18:14:31 Matthew Boyle wrote:
On 19/10/11 17:33, Matthew Boyle wrote:
it currently fails to build on Linux (Fedora 14, x64) when configured
using { --cc=g++ --ld=g++ --link=g++ }:
I'm also seeing intermittent failures in<t/pmc/alarm.t>. usually just
tests 3 and 4, occasionally 1 and 2, but i've seen the first four tests
all fail at once.
i've been able to consistently reproduce it thus:
COUNT=1; while prove t/pmc/alarm.t; do echo $((COUNT++)); done;
the failure seems to be extremely load-dependent (kicking off a couple
of { cat /dev/zero | sha384sum } pipelines in the background can make it
fail within a couple of iterations).
Thank you. That's an excellent test procedure.
I can reproduce it and it's pretty obvious, that the test itself is in error.
no problem! glad you found it useful.
i've not seen the problem since, so i think this can safely be
considered fixed :-)
The test assumes that the alarms will fire in the order in which they are set
and that they execute in the same order. But on a highly loaded system and
with active preemption it's no longer possible to tell which task will run in
which order. So the only meaningful tests are the "All alarms executed",
"Alarms actually waited" and "Alarm/sleep interaction" tests.
And even of these these, the "Alarms actually waited" test could wrongly
succeed and the "Alarm/sleep interaction" wrongly fail on an extremely loaded
system. But those are probably inherent with timer related tests.
yeah. fun things to test, aren't they? :-/
cheers,
--matt
--
Matthew Boyle, Systems Administrator, CoreFiling Limited
Telephone: +44-1865-203192 Website: http://www.corefiling.com
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
