non deterministic exception from withCreateProcess on Windows: "terminateProcess: permission denied (Permission denied)"

[sternmull]

On Windows the following program

module Main where
import System.Process
import System.IO

main :: IO ()
main = test 1

test i = do
  print i
  withCreateProcess ((shell "echo x") {std_out = CreatePipe}) $ \ _ (Just out) _ p -> do
    hGetChar out -- hGetLine and hGetContents have the same effect. But the problem disappears when this line is removed!
    return ()
  test $ i + 1

leads to output like this:

1
2
3
4
5
6
7
mytest.EXE: terminateProcess: permission denied (Permission denied)

Sometime it happens earlier sometimes it happens later. But as far i can tell it always happens pretty soon. I can not reproduce it on linux.

[snoyberg]

Unfortunately I don't know enough about the Win32 API to hazard a reasonable guess as to what's going on here. @Mistuke Could I bother you to look at this bug report and see if anything jumps out at you?

[Mistuke]

I don't think this is a bug in process, calling TerminateProcess will fail with an Access Denied when you don't have the rights to terminate the process or when the process is holding on to an object from a higher access level.

In this case what I think is happening is that the blocking calls to hGetChar end up creating IRPs which the kernel can't cancel for some reason. Reason may be buggy I/O driver, or a bug in the GHC I/O manager which would not be surprising. We might be creating requests which are issued not being cancellable because the I/O manager on Windows currently does not use native I/O facilities like IOCP. Instead relies on the pseudo posix interfaces which are largely un-maintained and deprecated.

That's why the issue goes away when you don't use an I/O function.

You can use a kernel mode debugger (like livekd) to inspect the IRPs when the process refused to die. I'll try to reproduce it later and see if I can find where it's going wrong.

[snoyberg]

Wow, thanks for the thorough and quick response :)

[sternmull]

See #111

[thomasjm]

Hi all -- I'm seeing this issue also, is #111 going to land?

[sternmull]

I still hope so. There was some misunderstanding in the discussion for #111 but in the end we agreed the fix is good.