[PATCH RFC] fork: remove cygpid.N sharedmem on fork failure

[Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>]

Hi,

I'm using attached patch for a while now, and orphan cygpid.N shared memory
instances are gone for otherwise completely unknown windows process ids.

However, I do see defunct processes now which's PPID does not exist (any more),
causing the same trouble because their windows process handle is closed but
their cygpid.N shmem handle is not.

For example, there is no PID 1768 anywhere, although it is the parent of both
the <defunct> processes:
$ ps -e
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
     2416       1    1496       2416  ?         197610   May 25 /usr/bin/python2.7
      560       1     560        560  ?         197613   May 25 /usr/bin/cygrunsrv
     2348       1    2348       2348  ?         197612   May 25 /usr/bin/cygrunsrv
     1132       1    1132       1132  ?         197612   May 16 /usr/bin/cygrunsrv
      440    2028     440        740  pty0      197609   May 29 /tools/haubi/gentoo/test/usr/bin/bash
     3664    1768    3612       3664  ?         197610 12:25:01 /usr/bin/python2.7 <defunct>
     2852    2704    2852       2364  ?         197612   May 25 /usr/sbin/sshd
     2268     560    2268       2128  ?         197613   May 25 /usr/libexec/sendmail
     2968    1768    3612       1500  ?         197610 12:25:01 /usr/bin/tail <defunct>
S    2832     512    2832       2312  pty0      197609 10:57:51 /usr/bin/vim
     2028    2852    2028       2000  pty0      197609   May 25 /usr/bin/bash
     1164    1132    1164       1256  ?         197612   May 16 /usr/sbin/cron
      512     440     512       1544  pty0      197609   May 29 /tools/haubi/gentoo/test/usr/bin/bash
     3264     512    3264       1488  pty0      197609 12:43:35 /usr/bin/ps
     2704    2348    2704       2856  ?         197612   May 25 /usr/sbin/sshd

That missing 1768 process for sure was started as (grand) children of 2416.

Problem is again that another fork'ed child processes with PID 1768, 2968, 3612
and probably others fail to initialize.

But I have no idea whether attached patch is causing or uncovering this issue...

Any idea?

Thanks!
/haubi/

>From 45e0fb72fea4fe32f572265c55135ff4dbd853ad Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Date: Tue, 5 Jun 2018 12:40:21 +0200
Subject: [PATCH] fork: remove cygpid.N sharedmem on fork failure

When fork finally fails although both CreateProcess and creating the
"cygpid.N" shared memory section succeeded, we have to release that
shared memory section as well - before releasing the process handle.
Otherways we leave an orphan "cygpid.N" shared memory section, and any
subsequent cygwin process receiving the same PID fails to initialize.

* fork.cc (frok::parent): Call child.allow_remove in cleanup code.
---
 winsup/cygwin/fork.cc | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/fork.cc b/winsup/cygwin/fork.cc
index c6fef6755..9451bb256 100644
--- a/winsup/cygwin/fork.cc
+++ b/winsup/cygwin/fork.cc
@@ -533,13 +533,16 @@ frok::parent (volatile char * volatile stack_here)
 
 /* Common cleanup code for failure cases */
 cleanup:
+  /* release procinfo before hProcess in destructor */
+  child.allow_remove ();
+
   if (fix_impersonation)
     cygheap->user.reimpersonate ();
   if (locked)
     __malloc_unlock ();
 
   /* Remember to de-allocate the fd table. */
-  if (hchild && !child.hProcess)
+  if (hchild && !child.hProcess) /* no child.procinfo */
     ForceCloseHandle1 (hchild, childhProc);
   if (forker_finished)
     ForceCloseHandle (forker_finished);
-- 
2.16.1