#10629: threadWaitRead throws BlockedIndefinitelyOnMVar -------------------------------------+------------------------------------- Reporter: | Owner: simonmar facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Runtime System | Keywords: Resolution: | concurrency sockets Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by facundo.dominguez: Old description:
In a project using the network-transport-tcp package, I'm observing {{{threadWaitRead}}} throw the exception {{{BlockedIndefinitelyOnMVar}}}.
The call stack is roughly:
{{{ ... n-t-tcp:Network.Transport.TCP.handleIncomingMessages n-t-tcp:Network.Transport.TCP.Internal.recvInt32 n-t-tcp:Network.Transport.TCP.Internal.recvExact network:Network.Socket.ByteString:recv network:Network.Socket.ByteString:recvInner network:Network.Socket.Internal:throwSocketErrorWaitRead base:Control.Concurrent:threadWaitRead }}}
IIUC this would be an RTS bug. The socket file descriptor is healthy and works fine if the exception is caught and {{{threadWaitRead}}} is retried.
Unfortunately, I can only reproduce this in a particular machine and with a rather complex test case.
I'd appreciate any advice on inspecting the RTS code to scan for the cause of {{{BlockedIndefinitelyOnMVar}}} being thrown.
Of course, if someone can help explaining this behavior I'll be most thankful.
New description: In a project using the network-transport-tcp package, I'm observing {{{threadWaitRead}}} throw the exception {{{BlockedIndefinitelyOnMVar}}}. The call stack is roughly: {{{ ... n-t-tcp:Network.Transport.TCP.handleIncomingMessages n-t-tcp:Network.Transport.TCP.Internal.recvInt32 n-t-tcp:Network.Transport.TCP.Internal.recvExact network:Network.Socket.ByteString:recv network:Network.Socket.ByteString:recvInner network:Network.Socket.Internal:throwSocketErrorWaitRead base:Control.Concurrent:threadWaitRead }}} IIUC this would be an RTS bug. The socket file descriptor is healthy and works fine if the exception is caught and {{{threadWaitRead}}} is retried. Unfortunately, I can only reproduce this in a particular cluster and with a rather complex test case while using the threaded runtime. I'd appreciate any advice on inspecting the RTS code to scan for the cause of {{{BlockedIndefinitelyOnMVar}}} being thrown. Of course, if someone can help explaining this behavior I'll be most thankful. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10629#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler