Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)
|Reported by:||kazu-yamamoto||Owned by:|
|Keywords:||Cc:||pho@…, andreas.voellmy@…, george.colpitts@…|
|Operating System:||MacOS X||Architecture:||x86_64 (amd64)|
|Type of failure:||Building GHC failed||Test Case:|
|Related Tickets:||Differential Rev(s):|
Description (last modified by )
Building GHC with parallel IO manager on Mac freezes when compiling the dph libraries in the phase 2.
We suspect this is due to a bug in the OS X implementation of kqueue, for the reasons given below. In the meantime, we have added an extra IO manager wakeup that appears to work around the problem; see
- This happens only if we specify "-j" to "make". Note that "make" closes stdin of sub-processes if "-j" is specified.
- Even if we specify "-j" to "make", the problem disappears with stdout/stderr redirection. That is, "make -jN >& LOG &" works.
- The "-d" option of "make" does not make any effects.
- Programs compiled with built GHC (with our patches) work well. For test, I compiled a daemon HTTP server which closes stdin/stdout/stderr. It worked well.
An IO manager is polling a kqueue fd. Another Haskell thread on another native thread registers an event through the same kqueue fd. In many cases, this works on Mac. In a certain situation, MacOS does not deliver an event to the IO manager. If the IO manager gets up and polls the kqueue fd, the event is delivered.
This bug only appears when building GHC on Mac. I cannot find a simple way to reproduce it. Even if we find a way to reproduce it, I guess that we will probably reach a conclusion that this is a bug of kqueue of Mac.
I have some evidences that kqueue of Mac is buggy:
Change History (21)
comment:19 Changed 20 months ago by
|Architecture:||Unknown/Multiple → x86_64 (amd64)|
|Status:||infoneeded → new|
comment:20 Changed 19 months ago by
|Priority:||high → normal|
|Status:||new → closed|