Skip to content

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

Description

@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.

Activity

  1. snoyberg commented on Nov 16, 2017

    @snoyberg
    Collaborator

    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?

  2. Mistuke commented on Nov 16, 2017

    @Mistuke
    Contributor

    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.

  3. snoyberg commented on Nov 16, 2017

    @snoyberg
    Collaborator

    Wow, thanks for the thorough and quick response :)

  4. added 2 commits that reference this issue on Nov 16, 2017
  5. sternmull commented on Nov 16, 2017

    @sternmull
    ContributorAuthor

    See #111

  6. thomasjm commented on Mar 6, 2018

    @thomasjm
    Contributor

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

  7. sternmull commented on Mar 8, 2018

    @sternmull
    ContributorAuthor

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

  8. added a commit that references this issue on Dec 9, 2018
  9. added a commit that references this issue on Dec 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions