On Feb  8 12:51, Michael Haubenwallner wrote:
> 
> 
> On 2/8/19 12:31 PM, Corinna Vinschen wrote:
> > On Feb  8 07:46, Michael Haubenwallner wrote:
> >>
> >> On 2/7/19 7:27 PM, Corinna Vinschen wrote:
> >>> On Feb  7 17:14, Michael Haubenwallner wrote:
> >>>> On 2/5/19 4:18 PM, Corinna Vinschen wrote:
> >>>>> Hi folks,
> >>>>>
> >>>>>
> >>>>> I uploaded a new Cygwin test release 3.0.0-0.7
> >>>>>
> >>>>
> >>>>> Please test.
> >>>>>
> >>>>
> >>>> There's another regression - regarding spawn, exec and waitpid,
> >>>> loosing the exitstatus somewhere in between:
> >>>>
> >>>
> >>> Any chance you could take a look?  I haven't much time for Cygwin the
> >>> next couple of days.
> >>
> >> Ok, will do. Any hints probably?
> > 
> > Thanks!  The only thing coming to mind is the removal of the parent
> > handle when switching PID method.  Or maybe the permission restriction
> > on the process handles?
> 
> For now it seems like there's an inconsistency with PIDs:
> A first process PID 100, receives PID 101 from spawn(),
> but in the new process getpid() returns 102:
> 
> $ ./dospawn /bin/bash -c 'echo $$'
> 12625
> waitpid: pid 12624 status 0x0

Oh, hmm.  If you call spawnve, rather than execve, a new child pid
is generated in spawnve, rather than just keeping the callers pid.

However, apparently the child invents its own pid in pinfo::thisproc
after being spawned.  But actually this should only occur for forked
processes aore processes started from non-Cygwin parents.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer