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:message-id:from:to:subject:in-reply-to
	:references:date; q=dns; s=default; b=v/CYP5O+lIneL0nYOLA4Ywfek+
	ywX0KHzjImESQbm1lFE8aB079ZOnA7S8ykC7az7dg9CdrfDBYmx8B0bhlxPUthU+
	GwMUDX6x9wIBcUFCi6vaNgMrbeWCqOVlp20LpLEa2daVx8hGyIJndo/XiZASz70a
	U/cDJa2SCSFT7w9Y4=
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:message-id:from:to:subject:in-reply-to
	:references:date; s=default; bh=e2ptbk6YeHaSG0IIVVOMLI5+qeg=; b=
	H2Y6Ej84KPTqWl9gKq8089FYPj0ucnp3Fsrs3RhtW9Fvtz4lDwR1LuY1grrihVat
	pPrFXleCuWbYqcS1j/67bC0vCFiE+1JnzJarnbkgzDtA4c5DtLmnLyZx8z4xauwF
	kEsnhERxbhOhddy0iAwBgLniIuov44ZsZEf1XQ8SZNQ=
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=0.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO: nm12-vm7.access.bullet.mail.bf1.yahoo.com
Message-ID: <670957.90887.bm@smtp117.sbc.mail.ne1.yahoo.com>
X-Yahoo-SMTP: BDVluRmswBBpb4.UU1_zlPhs_ysfXcBVjBNXyWpyS_6pPgE-
X-Rocket-Received: from solabel10.tnolan.com (tednolan AT 74 DOT 243 DOT 198 DOT 131 with plain [98.138.84.52])        by smtp117.sbc.mail.ne1.yahoo.com with SMTP; 16 Jan 2014 05:07:56 +0000 UTC
From: tednolan AT bellsouth DOT net
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
In-reply-to: <20140115163354.GA30234@calimero.vinschen.de>
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> <20140115163354 DOT GA30234 AT calimero DOT vinschen DOT de>
Comments: In-reply-to Corinna Vinschen <corinna-cygwin AT cygwin DOT com>   message dated "Wed, 15 Jan 2014 17:33:54 +0100."
Date: Wed, 15 Jan 2014 23:42:52 -0500
X-IsSubscribed: yes

In message <20140115163354 DOT GA30234 AT calimero DOT vinschen DOT de>you write:
>--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
>

Well, it appears I spoke too soon about Solaris.  I saw that it terminated
rather than running forever, and assumed it was working correctly.
That turns out not to be the case: For 3 lines in the input file, it somehow
gets up to 8 processes before terminating.

Here's what I can say per OS:

FreeBSD 4.9
FreeBSD 8.1
FreeBSD 9.1

	Original test case works.
	Test case with fclose() works
	Test case with _exit() instead of exit() works

Solaris 9:

	Original test case fails (but terminates)
	Test case with fclose() fails
	Test case with _exit() instead of exit() works

Cygwin:
	Original test case fails (never terminates)
	Test case with fclose() fails
	Test case with _exit() instead of exit() works

Gentoo Linux:
	Original test case works
	Test case with fclose() -- don't have access right now
	Test case with _exit() instead of exit() -- don't have access rght now

So, as per other posters, exit() is wrong and should be _exit().  I accept
that, and will fix it, but it still seems to be that the Linux and FreeBSD
behavior is better here.  If the spec allows "spooky action at a distance",
that's not the same as encouraging it..

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple