ghci panic: thread blocked indefinitely in an MVar operation

[pturnbull]

I stumbled across this error today:

phil ~
$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> 
[1]+  Stopped                 ghci
phil ~
$ fg
ghci
^C^C

Prelude> 
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.3 for i386-apple-darwin):
	thread blocked indefinitely in an MVar operation

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

phil ~
$

Steps to reproduce:

• start ghci
• ctrl-z
• fg
• ctrl-c
• ctrl-c
• enter
• wait ~2 seconds

I'm not sure if it is related but while waiting for the impossible to happen, any characters typed are not echoed to the screen.

[simonmar]

I don't see the bug on Linux, but I do see something else slightly strange. After foregrounding GHCi again, the first Ctrl-C brings up another Prelude> prompt which is fine, but if I then Ctrl-D to exit I get

Prelude> 
<stdin>: hWaitForInput: end of file

[simonmar]

Anyone with access to a Mac care to look into this one? It doesn't seem important enough to hold up the release for.

[Jafet]

I've encountered the same bug, but in the Windows console with GHC 7.0.1.

To reproduce:

1. Start ghci from cmd.exe (or Cygwin bash) in a console.
2. Press ^C.
3. Hold down the return key.

C:\>ghci
GHCi, version 7.0.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> ^C
C:\>
Prelude>
C:\>
Prelude>
C:\>

... after a moment ...

Prelude>
C:\>
Prelude>
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.0.1 for i386-unknown-mingw32):
        thread blocked indefinitely in an MVar operation

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


C:\>
C:\>

After ^C, GHC backgrounds itself from cmd.exe and subsequent input finds its way to the shell:

Prelude> ^C
C:\>
Prelude> input
'input' is not recognized as an internal or external command,
operable program or batch file.
C:\>input
'nput' is not recognized as an internal or external command,
operable program or batch file.

[Jafet]

Hi again. The previous message is incorrect; I didn't know that ghci.exe always uses a child ghc.exe process.

What really happens on Windows is that ghci.exe is right away killed by ^C, and the child ghc.exe doesn't realize that until a little later, so it goes into a panic. They also spawn some new threads before they die for some reason. I've attached a trace by Process Monitor, which records the syscalls made after ^C.

Someone with a Mac could ktrace to check that it's really the same bug.

[Jafet]

Syscall trace on Windows XP

[simonmar]

The Control-C behaviour on Windows was also reported as #4531.

[paterno]

I can verify this problem appears in the Mac OS X release as well. My output is below.

bash-$ uname -a
Darwin thomas 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:11:58 PST 2010; root:xnu-1504.9.26~3/RELEASE_X86_64 x86_64

bash-$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> 
[1]+  Stopped                 ghci
bash-$ fg
ghci
^C^C

Prelude> 
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.3 for i386-apple-darwin):
	thread blocked indefinitely in an MVar operation

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

[altaic]

I confirmed that this bug exists on my recent x86_64 HEAD build targeting OS X 10.6.

[Artyom.Kazak]

I'm using Windows 7, GHC 7.0.2. I don't know is it the same bug…

I was playing with my module called Helpers.Numeric located in file called Numeric.hs. As you can see, I compiled it using GHC and by mistake ran Numeric.hs instead of Numeric.exe, so I had GHCi in GHCi. Then I wanted to enter ':q', but entered just 'q', and the inner GHCi crashed.

*Helpers.Numeric Math.Root.Finder> :! ghc --make -O2 -main-is Halpers.Numeric Numeric.hs
[2 of 2] Compiling Helpers.Numeric  ( Numeric.hs, Numeric.o )
*Helpers.Numeric Math.Root.Finder> :! Numeric.hs
GHCi, version 7.0.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Ok, modules loaded: Helpers.Numeric, Ratio'.
Prelude Helpers.Numeric>
Prelude Helpers.Numeric> q

<interactive>:1:1: Not in scope: `q'
Prelude Helpers.Numeric>
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.0.2 for i386-unknown-mingw32):
        thread blocked indefinitely in an MVar operation

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

[fryguybob]

I've experienced the behavior from the last reporter on Windows with 7.0.2. For a while I've tried to get something repeatable to no avail. When it is happening it seems to happen fairly frequently. Some days I never run into it. I have never had it happen with HEAD which makes me suspect that #4531 fixed it. Some things that have triggered it for me:

• Typing q instead of :q (other things not in scope too).
• Hitting tab then y to display all.
• Pasting a long line. When it fails in this case I have been pasting a let expression and initially just an l shows. I hit backspace and paste again then it fails with the full line.

[simonmar]

Also reported in #5191

[modchan]

Issued fst ((1, 'a'),"foo"), GHCi answered correctly, but then crashed out with "thread blocked indefinitely in an MVar operation". Unfortunately, I cannot reproduce this.

[simonmar]

More reports of this bug: #5191 #5368 (also #5029 and #4000, but these had no info)

All the reports are on Mac or Windows.

[igloo]

With z.hs:

import Control.Concurrent
import Control.Exception
import Prelude hiding (catch)
import System.IO

main :: IO ()
main = do mv <- newEmptyMVar
          tid <- forkIO $ otherThread mv
          takeMVar mv
              `catch` \e ->
              do putStrLn ("Got exception: " ++ show (e :: SomeException))
                 putStrLn "Killing thread"
                 killThread tid
                 putStrLn "Killed thread"

otherThread :: MVar () -> IO ()
otherThread mv = do putStrLn "Waiting for input"
                    _ <- hWaitForInput stdin (-1)
                    putStrLn "There's some input"
                    putMVar mv ()

if we compile with HEAD on OS X (x86 or x86_64) with the threaded RTS:

ghc --make z -threaded

then run it, ^Z it, fg it, then ^C it, then the killThread blocks:

$ ./z
Waiting for input
^Z
[1]+  Stopped                 ./z
212:examples ian$ fg
./z
^CGot exception: user interrupt
Killing thread

Another ^C silently terminates the program.

It doesn't happen if:

• We don't do the ^Z/fg
• We don't use the threaded RTS
• It is run on Linux

So now the question is, why does it happen and how do we fix it?

(I believe Haskeline doing something like the above, mixed in with using an MVar, is the underlying case of the GHCi bug)

[igloo]

I have a hunch the problem will be around rts/posix/Signals.c sigtstp_handler and set_sigtstp_action.

[simonmar]

See also #5565

[simonmar]

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?