thread blocked indefinitely

[Dean Herington]

I've attached some clues below the quoted message.

On Thu, 20 Feb 2003, Dean Herington wrote:

> I'm getting intermittent "thread blocked indefinitely" errors with GHC
> 5.04.2.  My program uses modules Concurrent and Posix heavily.  In
> particular, I fork processes (now with GHC.Conc.forkProcess) and handle
> SIGCHLD signals to determine when the processes have finished.  The
> symptoms seem similar to "evacuated object entered" problems I had with
> GHC 5.02 and an earlier version of my program.  Any bugs or gotchas I
> should know about?  Suggestions about how to collect information with
> which to debug this problem?  (I've heard about +RTS -D1, IIRC, but have
> not tried it.  Is a debugging RTS available?  Is it possible for a mere
> mortal to build one?)

Something like the following seems to be occurring.

The program `Concurrent.forkIO`s several threads.  Two of these auxiliary
threads each fork a process (with `GHC.Conc.forkProcess`).  Just as the
second forked process is about to `Posix.executeFile`, it appears that the
"ghost" of the original thread (with ID 1) in that process--which is not
supposed to exist in the new process--suffers the "thread blocked
indefinitely" exception.  (Each of my threads protects itself with
`Exception.catch` and tags caught exceptions with process and thread IDs.)
It is likely that, in the original process, the original thread was
waiting on a `readChan` at the time of the `forkProcess`.

What I describe above happens nearly all the time.  However, one time I
observed something superficially quite different.  One of the processes (I
suspect the second forked one, as above, though since the message comes
from the RTS it isn't tagged with a process ID) reports:

Test: main thread exited (uncaught exception)

and then a bit later:

Test: fatal error: schedule: invalid what_next field

That process then exits with `ExitFailure 254`.


Any ideas and suggestions are welcome!

Dean