#2650: Child processes always unwantedly inherit Handles on Windows
----------------------------------+-----------------------------------------
Reporter: Deewiant | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone: 6.10.2
Component: libraries (other) | Version: 6.9
Severity: major | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Windows
Architecture: Unknown/Multiple |
----------------------------------+-----------------------------------------
Changes (by Deewiant):
* component: libraries/process => libraries (other)
* architecture: x86 => Unknown/Multiple
* summary: System.Process: processes may unwantedly inherit Handles on
Windows when multithreading => Child processes
always unwantedly inherit Handles on Windows
Comment:
Okay then, some info and bugfixes follow. Thanks a lot to dcoutts for
pointing me in the right direction and helping me along with this.
There are actually two issues, only one of which is (poorly) tested by
`createprocess-race-condition.hs`:
1. The race condition described in the Microsoft KB article.
2. The fact that all file handles are inheritable by default, meaning
that every child process always inherits them. This leads to errors if a
child is still alive when the parent wants to e.g. delete a file which was
open when the child was born.
The second issue is what is tested by the original test case. It only
happens sporadically because the file handle is kept open for a very brief
interval. The first issue I haven't managed to reproduce, but I don't see
a reason why it couldn't happen given the current code in `runProcess.c`.
Even if the second issue is fixed it should be possible that the anonymous
pipes for a child's stdin/out/err streams are inherited by some other
process.
I'm attaching:
1. A better test case for issue 2 above.
2. A patch against `base` which disables inheritance of file handles,
solving most cases of issue 2.
3. A tentative patch for issue 1 which I haven't tested properly, against
`process`: it wraps most of `runInteractiveProcess` in a critical section
for atomicity and rewrites the helper function `mkAnonPipe` to work as
described in the [http://support.microsoft.com/kb/315939 KB article
explaining the race condition issue].
Both patches are against the 6.10 darcs HEAD.
According to [http://msdn.microsoft.com/en-us/library/ms724466.aspx MSDN's
list of handle types that may be inherited], at least the `network`
library still needs to be changed: sockets shouldn't be inherited either.
(I don't think any of the other possible handles apply.) If anybody else
wants to do that bit, see [http://support.microsoft.com/kb/150523 this KB
article] for info on how it should be done. Note that the inheritance
disabling should be done atomically, to avoid the race condition described
above.
I'm pointing this bug at "libraries (other)" since it affects at least all
of `base`, `process`, and `network`.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2650#comment:3>
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
