An update on the GHC/FreeBSD front: I didn't manage to reproduce the
reported threading bugs on a UP, will be trying on a MP shortly.
However, I did discover one odd case that libpthread doesn't appear to
handle properly, but libthr does. This arose from a test in GHC's test
suite, but I've transliterated the code from Haskell to C:
$ cat thr1.c
#include
Simon Marlow wrote:
An update on the GHC/FreeBSD front: I didn't manage to reproduce the reported threading bugs on a UP, will be trying on a MP shortly.
Using -lthr instead of -pthread, I completed a test run on the dual proc box: OVERALL SUMMARY for test run started at Tue Aug 8 09:21:49 EDT 2006 1365 total tests, which gave rise to 6055 test cases, of which 0 caused framework failures 1034 were skipped 4944 expected passes 61 expected failures 4 unexpected passes 12 unexpected failures Unexpected passes: cholewo-eval(optasm,profasm) ffi009(optasm,profasm) Unexpected failures: barton-mangler-bug(normal,opt,prof,ghci,threaded) queryfdoption01(normal,opt,optasm,prof,profasm,threaded) rn.prog006(normal) Nothing to worry about here. I also discovered that we already have a fix in the HEAD's version of timeout that makes it work on FreeBSD (d'oh). The problem is that our timeout program forks and then calls system(), which forks again, and this is allegedly not allowed. I've merged that fix into STABLE now. I'm running the testsuite again with everything linked with -pthread and using the fixed timeout program. So far I haven't seen the other reported symptom, namely that the stage2 compiler sometimes hangs. Cheers, Simon
For the time being, I've committed a change that forces GHC to use -lthr on FreeBSD instead of whatever the default is (usually libpthread). This works around the hangs for me. If someone else on FreeBSD could verify this, I'd be grateful. You need to check out the 6.4 branch from CVS: $ cvs co -r ghc-6-4-branch fpconfig $ cd fptools $ cvs up -d hslibs libraries ghc testsuite Cheers, Simon
participants (2)
-
Simon Marlow -
Simon Marlow