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

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

On 06/07/2018 10:19 AM, Corinna Vinschen wrote:
> On Jun  5 15:05, Michael Haubenwallner wrote:
>> 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.
>>

>>
>> But I have no idea whether attached patch is causing or uncovering this issue...
>>
>> Any idea?
> 
> Not really.  Processes are kept around after exec to keep the PID
> blocked.  Perhaps your patch is breaking an assumption there.
> I wonder why you have a problem with failing forks in the first
> place...?

I'm successfully using the topic/forkables patches still, where
fork is retried using /var/run/cygfork/ when an exe or dll was
replaced (by some in-cygwin package manager).

Without this patch, for the first-try child process which the
cygwin1.dll fails to initialize for because of wrong dll loaded,
the process handle is released but the cygpid.N shmem handle is not.

Then, another completely independent process may get the same
windows process id again, and cygwin1.dll fails to initialize
because of the existing but orphaned cygpid.N shmem handle.

For those "Suspended" windows processes (sh.exe):
They seem to occur eventually when a shell script was executing some
native windows process (msvc toolchain). Interesting here is that
I got *4* Suspended sh.exe on the *4* core VirtualBox machine...

/haubi/