BlockedIndefinitelyOnMVar exception

[Neil Mitchell]

Hi Simon,

Thanks for the excellent information. I've now debugged my problem,
and think I've got the last of the MVar blocking problems out.

>> * How confident are people that this exception does really mean that
>> it is in a blocked state? Is there any chance the error could be
>> raised incorrectly?
>
> There have been one or two bugs in the past that could lead to this
> exception being raised incorrectly, but I'm not aware of any right now.
>  It's not inconceivable of course.

I have no reason to think it's broken. I found at least 3 separate
concurrency bugs in various parts (one added the day before, one over
a year old, one of which had been introduced while trying to work
around the MVar problem).

My suspicion for the root cause of the problem is that Concurrent.Chan
is incorrect. In the course of debugging this problem we found 2 bugs
in Chan, and while I never tracked down any other bugs in Chan, I no
longer trust it. By rewriting parts of the program, including avoiding
Chan, the bugs disappeared.I don't think I'll be using Chan again
until after someone has proven in correct.

>> * Any debugging tips for this problem?
>
> I'd use the event log: compile with -debug, run with +RTS -Ds -l, and dump
> the event log with show-ghc-events (cabal install ghc-events).  Or just dump
> it to stderr with +RTS -Ds, if the log isn't too large.  Use
> GHC.Exts.traceEvent to add your own events to the trace.

The event log is fantastic!

Thanks, Neil