Test concio001 failures on PPC Mac OS X
naur at post11.tele.dk
Wed Feb 20 14:28:44 EST 2008
I am unable to make the new test concio002 fail on the PPC Mac where I was
able to make concio001 fail. So that seems to have fixed the problem.
On Monday 18 February 2008 11:23, Simon Marlow wrote:
> naur at post11.tele.dk wrote:
> > Hello,
> > The test case concio001 fails like this on the PPC Mac OS X builder
tnaur-ppc-osx, most likely because of a simple timing problem:
> >> =====> concio001(normal)
> >> cd . && $MAKE -s --no-print-directory test.concio001 </dev/null
> >> Actual stdout output differs from expected:
> >> --- ./concio001.stdout.normalised 2008-02-06 08:18:52.000000000
> >> +++ ./concio001.run.stdout.normalised 2008-02-06 08:18:52.000000000
> >> @@ -1,2 +1 @@
> >> -child
> >> parent
> >> *** unexpected failure for concio001(normal)
> > Briefly, the test uses
> >> (sleep 1; echo x) | ./concio001
> > to run the program
> >> $ cat concio001.hs
> >> import Control.Concurrent
> >> main = do
> >> forkIO $ do threadDelay 100000; putStrLn "child"
> >> getLine
> >> putStrLn "parent"
> >> $
> > expecting the sleep 1 delay to be sufficient for the program to start
running, performing its threadDelay and printing the "child" string, before
the "parent" gets its input "x". But apparently, sleep 1 is insufficient in
> > If I run the test by hand, it succeeds. If I run the test alongside other
processes that tries to spend disk I/O bandwith and/or CPU and/or memory, I
am able to make it fail. So it appears that such circumstances are present
during the buildbot running of the concio001 test.
> > I am not sure how to cure this. I am confident that simply increasing the
sleep time would remove the problem in practice. However, perhaps some less
brittle solution could be found.
> While you're looking at this one, could you verify that we can now close
> I'm going to disable this concio001 test and replace it with one that is
> hopefully more reliable, I'll push after I've validated it.
More information about the Cvs-ghc