X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=iEzMpbVYVc/WZTMH7PpjWwfWdASl6WV4x5MvfLXy47fmqUhA5sEu9
	jC7RjM5TF/RSkus64VnDWj8t75DzMwIU8INV7gl03b7oZdVevFNyg9xPllQKvjaB
	RyTVvkjeZG8AZMeeV3EFopG3hHzNXGhLU39Bq6IAir5hpo/25wN2U8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=1SvxfoJRoniibedata0qJ4eIqmQ=; b=abpCtpVRsUZ7u/Y1n/Aajr309tAy
	j8xvTmDr2tAkGq13pkQ3vLGsvDiujwj6TERNW4l/+DMUrdwsiSEGSE/dAAN57S7f
	JzoT5f0w6mQLj6LMxiGAylwG0wtWvpySw5E0oGp0rClzDnQxjD/q/ApWYZItQsiT
	muCZ0rfasH8D3kk=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Wed, 15 Jan 2014 17:33:54 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
Message-ID: <20140115163354.GA30234@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <831845 DOT 98759 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com> <52D55D96 DOT 8070407 AT redhat DOT com> <946338 DOT 89157 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com> <CAG9p0OR8JYgC1rzBCn1bvXe5ffpJS3vpmnnxw-7brJi8E8+uhQ AT mail DOT gmail DOT com> <52D63CE2 DOT 9060308 AT lysator DOT liu DOT se> <858084 DOT 71265 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <858084.71265.bm@smtp116.sbc.mail.ne1.yahoo.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jan 15 10:28, tednolan AT bellsouth DOT net wrote:
> In message <52D63CE2 DOT 9060308 AT lysator DOT liu DOT se>you write:
> >On 2014-01-15 05:53, Lord Laraby wrote:
> >> On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote:
> >>> In message <52D55D96 DOT 8070407 AT redhat DOT com> you write:
> >>>>
> >>>> Your program may be violating POSIX, which would trigger undefined b=
ehavio
> >r.
> >>>>
> >>>> Quoting POSIX:
> >>>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#ta=
g_15_0
> >5
> >>>>
> >>>
> >>> [long quote elided]
> >>>
> >>> Yikes!  That's pretty impenatrable.  And if it says what I think it s=
ays,
> >>> it seems to violate the way I've understood Unix fork() and how fds
> >>> (and stdio buffers) are inherited since forever.
> >>>
> >>> However..
> >>>
> >>> Do I understand that to say that if the first thing my child does is
> >>>
> >>>         fclose(fp);
> >>>
> >>> everything should be hunky-dory?
> >>>
> >>> Because I just tried that, and it's still not.
> >>=20
> >> My two cents say, since the child is not referencing 'fp' at all,
> >> there is no violation of the POSIX semantics in this situation. It
> >> actually does seem, however, that the fork is closing, or at least
> >> forgetting the stdio file position of, fp when it forks. A possible
> >> memory corruption during fork from which fgets can not recover?
> >
> >Let me requote one little bit quoted by Eric:
> >
> >	                           (If the only action performed by one of the
> >	processes is one of the exec functions or _exit() (not exit()), the
> >	handle is never accessed in that process.)
> >
> >Ted is using exit() in the children, not _exit(), and the above indicates
> >that exit() in fact "accesses the handle". My guess would be that fclose=
(3)
> >also "accesses the handle".
> >
> >But, reading about _exit(), it seems that handle accesses are implementa=
tion
> >defined, so I'm not sure it will help in all situations.
> >
> >Cheers,
> >Peter
>=20
> Well, all I can say in this instance, is that arguably conforming to
> the bare letter of the standard (if that's in fact what is happening)
> is not "the right thing".  People certainly don't expect that stdio
> file pointers that exist at fork() time and which are never "used" by a
> child will be reset in the parent.  I mean, if they can't even be fclose(=
)-ed
> to take them out of the picture, what chance have you got? -:)
>=20
> FWIW, FreeBSD, Linux and Solaris all compile and run the test program
> with the behavoir I expect..

Just for completeness:  I can test on Linux, but not on FreeBSD and
Solaris.  Does the testcase also work as expected on both of them,
after you added fclose to the child?  On Linux it does.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJS1rhyAAoJEPU2Bp2uRE+gVXcP/jKVEtguaLpf3PQ1Qxwfxicz
CqN9tn64EZaS6TcSmIp5QtkeA6bRshvzttaYusA8KgVqAitW+JyFtwOC6PqV+JW7
mg/TxLeJoq978E+Zgypfjm5FF+7E/ZefLpXD6YvaTNLCPa1mFRDVMZf7FqbUMkjL
A2GwvIMlS1ZlGEn7nk7R7JAD1d2dTKT8hlVmoY7OMgYyu1xfoGDdKXqlsi5eSPYF
54H1g0xvT5I/UIxnt3RC3D3Qdubx0ze8sK2umsW5SO82FUqQZ5leWtJ6XWJijZxh
Gh/tOf1GqdimQdyymg8HDnQDOs3vpyma+shXMU6lHU2pOvCkA72bI9iFveasNUIR
KCxwk6xAISp9yGMo7ss56mkaXAftgtwViicnp9K9QjlVXw47dspcLwUBuR3aFxPq
FvqcWPEv0OKulOPNVu6MIKBs127lpQxfVDzre9KBO6CfRwl9sCpkFyGNxgNqVPPU
eM5cJydCNBxXVpwPjrKx5qxZL4c/goFRFV33XrVMJMyGvqdbA/DM5mGJi9ajr80T
7a6jt3CGottZQB0xcxzc4081QdV7ONVmaic2jGiV8Z+DeBWkn+/dsdYOByMGex58
J+mLHWoCRvIABmxPjtazILjg0uWOxqW1zzcOHFkSmSUivfg3aAzIdfh0upIivxNP
xAy0lt0zSAfFVDTEoanS
=1DAE
-----END PGP SIGNATURE-----

--ew6BAiZeqk4r7MaW--