#2650: System.Process: processes may unwantedly inherit Handles on Windows when
multithreading
-------------------------+--------------------------------------------------
Reporter: Deewiant | Owner: simonmar
Type: bug | Status: new
Priority: normal | Component: libraries/process
Version: 6.9 | Severity: major
Keywords: | Testcase:
Architecture: x86 | Os: Windows
-------------------------+--------------------------------------------------
`runInteractiveProcess` (the one in `runProcess.c`, not the Haskell one)
calls `CreateProcess` with `bInheritHandles` set to `TRUE`, but the whole
thing is not wrapped in a critical section. Microsoft has
[http://support.microsoft.com/kb/315939 a decent explanation of why this
is a problem] and I found that it's
[http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6428742 a two-year old
unfixed bug in the Java runtime] as well.
In case it's not obvious, the reason why we don't want Handles to be
inherited is that then a child process may hang on to it well after it
should have been closed. The end result is that trying to do anything to
it results in a sharing violation. The case in which I originally ran into
this was `System.Directory.copyFile` intermittently reporting a
"permission denied" error for a temp file it was using. I think it was
trying to delete it, but failing because a child process somewhere was
hanging on to the Handle.
Attached is code demonstrating the problem. It forks a thread which
repeatedly tries to open and close the file `foo.tmp`. The main thread
then spawns processes as fast as it can until the other one fails to open
the file. This, I think, cannot happen on non-Windows platforms since two
processes can have the same file open without trouble. '''Do not run
except on Windows, you risk flooding your system with `ping` processes.'''
It may be sensible to make this controllable with the `close_fds`
parameter to `createProcess`, which is currently just ignored on Windows.
I can't see why anybody could ever want this behaviour, though.
I've tested only process-1.0.1 with it, and the `openFile` fails reliably
after spawning up to about 4 processes.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2650>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs