From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99703 invoked by alias); 8 Feb 2019 13:06:42 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 99689 invoked by uid 89); 8 Feb 2019 13:06:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-125.4 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Feb 2019 13:06:40 +0000 Received: from calimero.vinschen.de ([217.91.18.234]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N3sNa-1hIWeC3NNA-00zlF9; Fri, 08 Feb 2019 14:06:36 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 0A312A8045C; Fri, 8 Feb 2019 14:06:36 +0100 (CET) Date: Fri, 08 Feb 2019 13:06:00 -0000 From: Corinna Vinschen To: Michael Haubenwallner Cc: cygwin@cygwin.com Subject: Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7 Message-ID: <20190208130635.GO13951@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Michael Haubenwallner , cygwin@cygwin.com References: <02da4eeb-fcce-b1bc-e6eb-68ff3ec0cf74@ssi-schaefer.com> <20190207182735.GG13951@calimero.vinschen.de> <8a2f041f-f8f7-6e17-5d97-5a168440009b@ssi-schaefer.com> <20190208113158.GH13951@calimero.vinschen.de> <17e339bb-2115-bf22-7291-04215aab3150@ssi-schaefer.com> <20190208122126.GM13951@calimero.vinschen.de> <20190208122338.GN13951@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LQAwcd5tHl0Qlnzi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2019-02/txt/msg00071.txt.bz2 --LQAwcd5tHl0Qlnzi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2443 On Feb 8 13:52, Michael Haubenwallner wrote: >=20 >=20 > 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. > >=20 > > Does that help, by any chance: > >=20 > > 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 =3D NULL; > > + h =3D INVALID_HANDLE_VALUE; > >=20=20 > > /* Setup our write end of the process pipe. Clear the one in the st= ructure. > > 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 =3D create_cygwin_pid (); > > flags |=3D PID_NEW; > > } > > + else if (h =3D=3D INVALID_HANDLE_VALUE) > > + h =3D NULL; >=20 > No, because cygheap->pid still is the parent's pid here, not the new chil= d's one. >=20 > How should the child be informed at all about the new cygpid value genera= ted 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 --=20 Corinna Vinschen Cygwin Maintainer --LQAwcd5tHl0Qlnzi Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxdftsACgkQ9TYGna5E T6BvIg//awSoSeWhbq0rCTtNlo+SBm7c+djs4e0n8BMgz40eKwsJWupSp3HTHjmJ dX2rBieErEFp/IbbMTM1No+JyRtBFgtC8GoL/mO6aaZpumQ67i5Vws8pxvwNtsDs ROpqLofJyG/jGwTOWMfMjROqMwToah8nyU9PvZ88zsvOeDWhSJ1XrcZfp69iitmR zzC1CgvhQajuuvQZnP9P4TbUt+tiNzHtu8VFBdsZ/yEW1LzPF09o/giBBHs8Z7vQ 0+tHhJaaq8S/WduSo6J0ULL0zQFVY5QaBBsSmHBhyPQ+UTmmKyy1e/nbR8P8Uy4Q B2/kRQTQP5PfsCdvCIGOih82URKExaD0R2Fkuizz1jNt9vtlw6ttbyNgrSetHbsx 1KfdyllM8Wmmp4q9oI71/75xVicIshTsgLFzt4+bctEHGKZnDbg+EkFJD/FT1MG8 H50AMwc0IczqqTLi5sh1//g/45TGQnUKhFXPsibJstYRGuGSXNmETe5sad1qkJfj WeCvgfTHE7FoY0LFzEg4QSo7jq6kQRvZ6ph2oPwKj2uti4n6yyODP/nhTXRc/VDN z9jI0NWzXFtg5X7S9XwBFaB3Agaq2nYGiIhxepUZ+Owqv7PDGGQEouGo+a5kMM7M M2pzfg4acbLNvbzJjy/077EBnq1U79QLViyoLonMgSEpqntbqE4= =tg3U -----END PGP SIGNATURE----- --LQAwcd5tHl0Qlnzi--