[PATCH, libiberty] Pex pipes block under win32 when parent process dies

[Julian Brown]

Hi,

This patch addresses a problem where child processes started using the
libiberty 'pex' mechanism could block indefinitely when trying to write
to the parent if the parent exits unexpectedly. We (at CodeSourcery)
observed this happening in gdb when starting a debug stub like so:

  (gdb) target remote | /path/to/stub ...

though it's possible it could occur under other circumstances too
(though I'm not sure which). In the above case, if gdb is killed using
e.g. the task manager in Windows, the stub (which tries to output to
stderr then fflush()) will block and fail to exit.

The rationale behind the patch is borrowed from the MSDN page:

  http://msdn.microsoft.com/en-us/library/aa298531.aspx

IIUC, at the moment, the child is spawned and inherits open descriptors
for both ends of the pipe. Under Win32, you don't get EOF on a pipe
until all of the copies of the write end of the pipe are closed, so
that won't happen if the parent alone dies.

The change in pex_win32_pipe() means that the child will get neither
end of the pipe by default. So we duplicate the in/out/error
descriptors in pex_win32_exec_child() to get inheritable versions to
pass to the child, then close the originals. After spawning, we close
the duplicates. Then since the parent ends up with no copies of the
write end of the pipe, if it exits it won't cause the child to block.

This seems to suffice to fix the problem described above. OK to apply
to the Sourceware/GCC copies of libiberty?

Cheers,

Julian

ChangeLog

    libiberty/
    * pex-win32.c (pex_win32_pipe): Add _O_NOINHERIT.    
    (pex_win32_exec_child): Ensure each process has only one handle
    open on pipe endpoints. Close standard input after creating child
    for symmetry with standard output/standard error.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pex-no-inherit-2.diff
Type: text/x-patch
Size: 2363 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20090427/ec7fc43d/attachment.bin>