#4245: ghci panic: thread blocked indefinitely in an MVar operation
-------------------------------+--------------------------------------------
Reporter: pturnbull | Owner: tibbe
Type: bug | Status: new
Priority: high | Milestone: 7.4.1
Component: GHCi | Version: 6.12.3
Keywords: MVar | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: GHCi crash
-------------------------------+--------------------------------------------
Changes (by simonmar):
* cc: bos (added)
* owner: igloo => tibbe
Comment:
There's an even simpler example:
{{{
main :: IO ()
main = do putStrLn "Waiting for input"
getChar
putStrLn "There's some input"
}}}
reproduce by:
* run the program (on OS X)
* suspend with `^Z`
* resume with `fg`
* Now hit `^C`: observe that nothing happens
* (another `^C` kills the program)
Without the `^Z/fg` combination first, the `^C` signal works as it should.
What appears to be happening is this:
* the main thread is blocked in `threadWaitRead` on FD 0
* on resumption, `threadWaitRead` returns
* thinking that there is data to be read, we now call `read()` (this is
in `GHC.IO.FD.readRawBufferPtr`)
* there is actually no data to read, so `read()` blocks
I believe the bug is that `threadWaitRead` returns when it shouldn't, so
I'm punting this to the IO manager maintainers. Johan/Bryan?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
