Handle is closed error

[snoyberg]

Originally reported as fpco/fpco#221. Please see there for the actual use case.

The following (also available from: https://gist.github.com/raw/14234504f980bd1f1ccb/4309cf9fc7dca5332137cd88204c5c097dd9a6a2/issue221.hs) is a reproducing test case for this issue. The test runs against the ide-backend code directly, without any fpco code involved. I've also added a test case to isolation-runner: https://github.com/fpco/fpco/commit/13e7b06a98716744e65070c0b427fb71d6e0dee3

{-# LANGUAGE OverloadedStrings #-}
import IdeSession
import ModuleName
import Data.Monoid
import Test.HUnit

main = do
    session <- initSession $ SessionConfig "/home/ubuntu/Desktop/tmp" []
    let main' = ModuleName ["Main"]
    {-

    let updates1 = mconcat
            [ updateCodeGeneration True
            , updateModule main' "main = putStrLn \"Hi!\" >> getLine"
            , updateStdoutBufferMode $ RunLineBuffering Nothing
            ]
    updateSession session updates1 $ const $ return ()
    ra1 <- runStmt session main' "main"
    out1a <- runWait ra1
    out1a @?= Left "Hi!\n"
    interrupt ra1
    out1b <- runWait ra1
    out1b @?= Right (RunProgException "AsyncException: user interrupt")
    -}

    let updates2 = mconcat
            [ updateCodeGeneration True
            , updateModule main' "main = interact id"
            , updateStdoutBufferMode $ RunLineBuffering Nothing
            ]
    updateSession session updates2 $ const $ return ()
    ra2 <- runStmt session main' "main"
    supplyStdin ra2 "hello\n"
    out2a <- runWait ra2
    out2a @?= Left "hello\n"
    interrupt ra2
    out2b <- runWait ra2
    out2b @?= Right (RunProgException "AsyncException: user interrupt")

    let updates3 = mconcat
            [ updateCodeGeneration True
            , updateModule main' "main = putStrLn \"Hi!\" >> getLine"
            , updateStdoutBufferMode $ RunLineBuffering Nothing
            ]
    updateSession session updates3 $ const $ return ()
    ra3 <- runStmt session main' "main"
    out3a <- runWait ra3
    out3a @?= Left "Hi!\n"
    supplyStdin ra3 "Michael\n"
    out3b <- runWait ra3
    out3b @?= Right (RunOk "it{v air}")

This is high priority for us, since it can mean that a user's session becomes completely non-responsive.

[snoyberg]

Note: I just tested against both the master and experimental branches; both produce the same result:

test.hs: HUnitFailure "expected: Right (RunOk "it{v air}")\n but got: Right (RunProgException "IOException: : hGetLine: illegal operation (handle is closed)")"

[edsko]

Ok, I can reproduce this. Looking at this now.

[edsko]

I can reproduce this even without ide-backend at all:

module Main where

import Control.Concurrent

main :: IO ()
main = do
  tid <- forkIO $ interact id
  threadDelay 1000000
  killThread tid
  putStrLn "Hi"
  getLine >>= putStrLn

Apparently the killThread of a thread that does lazy IO closes the corresponding handle. Nasty lazy I/O..

(Of course, this is an instance of a more general problem: when a snippet closes its stdin or stdout then this affects the next run. We will need to isolate this.)

[edsko]

Hmm, actually, I thought we did isolate that. We create new pipes for every runStmt. Interesting.

[edsko]

Ok, we do isolate different runs of runStmt using different pipes, but unfortunately the Haskell-land Handle it (stdout, stdin) is an unsafePerformIO of a handle creation, gets closed when by the first snippet, and apparently the next snippet shares the same address space as the previous and gets that same closed Handle, even though the underlying pipe has been changed.

[edsko]

Ok, the above comment is correct. I have fixed this in the experimental branch using some quite low-level coding, manually resetting stdin, stdout and stderr on every runStmt. This is ugly, but I don't know of a better way around it. I haven't merged this with master yet because there is one unit test still failing ("Maintain list of compiled modules"), which appears to be a genuine bug somewhere.

[edsko]

Ok, the failing unit test is unrelated and due to a ghc bug which we now work around. Closing this issue.