Re: BlockedIndefinitelyOnMVar exception

2010-06-26 Thread nccb2
 Hi,

 I have a very big and highly threaded program that generates a
 BlockedIndefinitelyOnMVar exception when run. I have spent a
 reasonable amount of time pouring over the source code, as has Max
 Bolingbroke. Neither of us have the slightest idea why it raises the
 exception.

 Some questions:

 * Does anyone know the exact sequence of actions that causes this
 exception to be thrown? I couldn't find it written down.
 * 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?
 * Any debugging tips for this problem?

My understanding was that this error occurred when one thread was blocked,
waiting on an MVar, and no other thread in the program has a reference to
that MVar (this can be detected during GC).  Ergo, the blocked thread will
end up waiting forever because no-one can ever wake it up again.

Whenever I have had this error (or its STM equivalent) I think it was
always telling the truth.  I seem to remember it was often a symptom of
another thread terminating unexpectedly.  So if thread A is blocked on an
MVar that it is expecting thread B to write to, then thread B terminating
can cause this error to arise in thread A, even though the real problem is
in thread B.

Do you actually have use of MVars in your program directly, or are they
being used via a library?  And do you at least know which thread is
throwing this exception?  It should be catchable so you can probably wrap
the arguments to your forkIO calls with a catcher than indicates which
thread blew up.

Thanks,

Neil.



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: BlockedIndefinitelyOnMVar exception

2010-06-26 Thread Neil Mitchell
 My understanding was that this error occurred when one thread was blocked,
 waiting on an MVar, and no other thread in the program has a reference to
 that MVar (this can be detected during GC).  Ergo, the blocked thread will
 end up waiting forever because no-one can ever wake it up again.

That certainly seems a sensible rule - I'll see if that can help me
debug my problem.

 Do you actually have use of MVars in your program directly, or are they
 being used via a library?  And do you at least know which thread is
 throwing this exception?  It should be catchable so you can probably wrap
 the arguments to your forkIO calls with a catcher than indicates which
 thread blew up.

I use MVar's directly, use Chan/QSem, and have about 5 concurrency
data types built on top of MVar's - they're everywhere.

I also have a thread pool structure, so tasks move between threads
regularly - knowing which thread got blocked isn't very interesting.

Thanks for the information,

Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users