[GHC] #7656: qsemn001 randomly fails on OS X x86

#7656: qsemn001 randomly fails on OS X x86 ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ `qsemn001` randomly fails on OS X x86 (119 times out of 1000), but never on Linux amd64 (tried 1000 times). e.g.: {{{ $ make CLEANUP=1 TEST=qsemn001 WAY=normal python ../../../testsuite/driver/runtests.py -e ghc_compiler_always_flags ="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=False -e darwin=True -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../testsuite/config/ghc -e 'config.confdir="../../../testsuite/config"' -e 'config.compiler="/Users/ian/ghc/git/val32/inplace/bin/ghc-stage2"' -e 'config.ghc_pkg="/Users/ian/ghc/git/val32/inplace/bin/ghc-pkg"' -e 'config.hp2ps="/Users/ian/ghc/git/val32/inplace/bin/hp2ps"' -e 'config.hpc="/Users/ian/ghc/git/val32/inplace/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="i386-apple-darwin"' -e 'config.os="darwin"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup="1"' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../testsuite/timeout/install- inplace/bin/timeout"' -e 'config.exeext=""' -e 'config.top="/Users/ian/ghc/git/val32/testsuite"' \ --only=qsemn001 \ \ --way=normal \ \ \ Timeout is 300 Found 6 .T files... Beginning test run at Sun Feb 3 21:52:50 GMT 2013 ====> Scanning ./all.T ====> Scanning ./Concurrent/all.T ====> Scanning ./IO/all.T ====> Scanning ./Numeric/all.T ====> Scanning ./System/all.T ====> Scanning ./Text.Printf/all.T =====> qsemn001(normal) 69 of 156 [0, 0, 0] cd . && '/Users/ian/ghc/git/val32/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs >qsemn001.comp.stderr 2>&1 cd . && ./qsemn001 qsemn001.run.stdout 2>qsemn001.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: test semn test semn2 Stderr: qsemn001: "acb" /= "abc" *** unexpected failure for qsemn001(normal) OVERALL SUMMARY for test run started at Sun Feb 3 21:52:50 GMT 2013 156 total tests, which gave rise to 1068 test cases, of which 0 caused framework failures 1067 were skipped 0 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 1 unexpected failures Unexpected failures: . qsemn001 [bad exit code] (normal) }}} The actual failure varies: {{{ $ grep "qsemn001:" out | sort | uniq -c 30 qsemn001: "acb" /= "abc" 34 qsemn001: "ba" /= "ab" 55 qsemn001: "bac" /= "abc" }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7656 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7656: qsemn001 randomly fails on OS X x86
-------------------------------+--------------------------------------------
Reporter: igloo | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: libraries/base | Version: 7.7
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
-------------------------------+--------------------------------------------
Changes (by simonmar):
* status: new => closed
* resolution: => fixed
Comment:
Fixed, I hope. It looks like small delays aren't as accurate on OS X as
they are on Linux, but in any case this test was fragile so it's a good
thing to fix it. It might be a good idea for someone to look into why the
delays weren't accurate on OS X, but it may just be that there's only a
20ms resolution for the `select` timeout or something.
{{{
commit 975ea1a7bbd1aa129f5c3b0cb4eb0dfb74780a0b
Author: Simon Marlow
participants (1)
-
GHC