Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]

On Feb  8 13:52, Michael Haubenwallner wrote:
> 
> 
> On 2/8/19 1:23 PM, Corinna Vinschen wrote:
> > On Feb  8 13:21, Corinna Vinschen wrote:
> >> On Feb  8 12:51, Michael Haubenwallner wrote:
> >>>
> >>> 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.
> > 
> > Does that help, by any chance:
> > 
> > diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
> > index 78506d43de29..0b274287d9f6 100644
> > --- a/winsup/cygwin/dcrt0.cc
> > +++ b/winsup/cygwin/dcrt0.cc
> > @@ -656,7 +656,7 @@ child_info_spawn::handle_spawn ()
> >        !DuplicateHandle (GetCurrentProcess (), moreinfo->myself_pinfo,
> >  			GetCurrentProcess (), &h, 0,
> >  			FALSE, DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE))
> > -    h = NULL;
> > +    h = INVALID_HANDLE_VALUE;
> >  
> >    /* Setup our write end of the process pipe.  Clear the one in the structure.
> >       The destructor should never be called for this but, it can't hurt to be
> > diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc
> > index 445bd35b224e..d10c4fc4580c 100644
> > --- a/winsup/cygwin/pinfo.cc
> > +++ b/winsup/cygwin/pinfo.cc
> > @@ -62,6 +62,8 @@ pinfo::thisproc (HANDLE h)
> >        cygheap->pid = create_cygwin_pid ();
> >        flags |= PID_NEW;
> >      }
> > +  else if (h == INVALID_HANDLE_VALUE)
> > +    h = NULL;
> 
> No, because cygheap->pid still is the parent's pid here, not the new child's one.
> 
> How should the child be informed at all about the new cygpid value generated in
> parent's child_info_spawn::worker() ?

I just realized this myself.  The old method creating Cygwin pids just
fetched the pid from GetCurrentProcessId(), which was right for spawned
(but not execed) processes.  For the new pid we might have to give this
to the child via child_info_spawn.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]