Hello, 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.
Best regards Thorkil On Monday 18 February 2008 11:23, Simon Marlow wrote: > [EMAIL PROTECTED] 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 >concio001.run.stdout 2>concio001.run.stderr > >> Actual stdout output differs from expected: > >> --- ./concio001.stdout.normalised 2008-02-06 08:18:52.000000000 +0100 > >> +++ ./concio001.run.stdout.normalised 2008-02-06 08:18:52.000000000 +0100 > >> @@ -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 some cases. > > > > 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 #1523? > > http://hackage.haskell.org/trac/ghc/ticket/1523 > > 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. > > Cheers, > Simon > _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
