Opened 4 years ago

Last modified 7 months ago

#4245 new bug

ghci panic: thread blocked indefinitely in an MVar operation

Reported by: pturnbull Owned by: tibbe
Priority: high Milestone: 7.6.2
Component: GHCi Version: 6.12.3
Keywords: MVar Cc: william.knop.nospam@…, fryguybob@…, malicious.wizard@…, bos, mihai.maruseac@…, pho@…
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: GHCi crash Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Attachments (1)

ghci-xp-trace.csv (2.7 KB) - added by Jafet 3 years ago.
Syscall trace on Windows XP

Download all attachments as: .zip

Change History (31)

comment:1 Changed 4 years ago by 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

comment:2 Changed 4 years ago by igloo

  • Milestone set to 6.14.1
  • Priority changed from normal to high

comment:3 Changed 4 years ago by simonmar

  • Priority changed from high to normal

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

comment:4 Changed 3 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:5 Changed 3 years ago by Jafet

  • Operating System changed from MacOS X to Unknown/Multiple
  • Version changed from 6.12.3 to 7.0.1

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.

comment:6 Changed 3 years ago by 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.

Changed 3 years ago by Jafet

Syscall trace on Windows XP

comment:7 Changed 3 years ago by simonmar

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

comment:8 Changed 3 years ago by paterno

  • Architecture changed from x86 to x86_64 (amd64)
  • Operating System changed from Unknown/Multiple to MacOS X
  • Version changed from 7.0.1 to 6.12.3

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

comment:9 Changed 3 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:10 Changed 3 years ago by altaic

  • Cc william.knop.nospam@… added

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

comment:11 Changed 3 years ago by 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

comment:12 Changed 3 years ago by fryguybob

  • Cc fryguybob@… added

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.

comment:13 Changed 3 years ago by simonmar

Also reported in #5191

comment:14 Changed 3 years ago by modchan

  • Cc malicious.wizard@… added

comment:15 Changed 3 years ago by 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.

comment:16 Changed 3 years ago by simonmar

  • Priority changed from normal to high

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

All the reports are on Mac or Windows.

comment:17 Changed 3 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:18 Changed 3 years ago by igloo

  • Owner set to igloo

comment:19 Changed 3 years ago by 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)

comment:20 Changed 3 years ago by igloo

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

comment:21 Changed 2 years ago by simonmar

See also #5565

comment:22 Changed 2 years ago by simonmar

  • Cc bos added
  • Owner changed from igloo to tibbe

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??

comment:23 Changed 2 years ago by igloo

  • Difficulty set to Unknown
  • Milestone changed from 7.4.1 to 7.4.2

comment:24 Changed 2 years ago by igloo

  • Owner changed from tibbe to igloo

comment:25 Changed 23 months ago by igloo

  • Milestone changed from 7.4.2 to 7.4.3

comment:26 Changed 23 months ago by mihai.maruseac

  • Cc mihai.maruseac@… added

comment:27 Changed 19 months ago by igloo

  • Milestone changed from 7.4.3 to 7.6.2

comment:28 Changed 17 months ago by tibbe

  • Owner changed from igloo to tibbe

comment:29 Changed 13 months ago by PHO

  • Cc pho@… added

comment:30 Changed 7 months ago by simonmar

Also reported as #7698

Note: See TracTickets for help on using tickets.