delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2014/01/14/10:54:21

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:date:from:mime-version:to:subject
:references:in-reply-to:content-type; q=dns; s=default; b=jjXwmW
Y01P97uTJ/gkWtQop5ihmpBQrj2FDZeUNJmS0mIAvKEaoeUqiwaLUKAJ9gG5nhN3
7bgujNWCzGmZM0bk21KY6DVmCJNaBAa9uWBfl9i21MEYcD4/hvTBPXZLDKf2Jp8f
gkEyYd9Jbef+mjm/NGnczM/EjAJNTT2CGW720=
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:date:from:mime-version:to:subject
:references:in-reply-to:content-type; s=default; bh=mwebRYlnMIHW
YdMzjj65oQEeASw=; b=lTpKGCnoE0me0iEOLVzG2hrOtYWyB/aqwI3qByMzdD8m
4PiIomyvjthAHbn6hgGkhLwc06/CChCB3Cd4caRURmxQmv0Z1Wq9+4Jt93+qrtn+
JmcG+5Fj9d8sZLs4ZnjupSKa3A9vp1ERua49H1DwJ5epSkyF42ROTWa+DD0+diI=
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=-1.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mx1.redhat.com
Message-ID: <52D55D96.8070407@redhat.com>
Date: Tue, 14 Jan 2014 08:53:58 -0700
From: Eric Blake <eblake AT redhat DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
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
References: <831845 DOT 98759 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com>
In-Reply-To: <831845.98759.bm@smtp116.sbc.mail.ne1.yahoo.com>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
X-IsSubscribed: yes

--TJrX8LL8tj0njctvOsdGO9fVrHmw5jHio
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/13/2014 09:06 AM, tednolan AT bellsouth DOT net wrote:
> Hello,
>=20
> I'm running:
>=20
> CYGWIN_NT-6.1 prog5 1.7.27(0.271/5/3) 2013-12-09 11:54 x86_64 Cygwin
> gcc (GCC) 4.8.2
>=20
> on a 64 bit Win7 system.
>=20
> I have just run into an odd bug, which I have boiled down into the program
> below (which started as a mod to tiff2ps).

Your program may be violating POSIX, which would trigger undefined behavior.

Quoting POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#ta=
g_15_05

For a handle to become the active handle, the application shall ensure
that the actions below are performed between the last use of the handle
(the current active handle) and the first use of the second handle (the
future active handle). The second handle then becomes the active handle.
All activity by the application affecting the file offset on the first
handle shall be suspended until it again becomes the active file handle.
(If a stream function has as an underlying function one that affects the
file offset, the stream function shall be considered to affect the file
offset.)

The handles need not be in the same process for these rules to apply.

Note that after a fork(), two handles exist where one existed before.
The application shall ensure that, if both handles can ever be accessed,
they are both in a state where the other could become the active handle
first. The application shall prepare for a fork() exactly as if it were
a change of active handle. (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.)

For the first handle, the first applicable condition below applies.
After the actions required below are taken, if the handle is still open,
the application can close it.

    If it is a file descriptor, no action is required.

    If the only further action to be performed on any handle to this
open file descriptor is to close it, no action need be taken.

    If it is a stream which is unbuffered, no action need be taken.

    If it is a stream which is line buffered, and the last byte written
to the stream was a <newline> (that is, as if a:

        putc('\n')

    was the most recent operation on that stream), no action need be taken.

    If it is a stream which is open for writing or appending (but not
also open for reading), the application shall either perform an
fflush(), or the stream shall be closed.

    If the stream is open for reading and it is at the end of the file
(feof() is true), no action need be taken.

    If the stream is open with a mode that allows reading and the
underlying open file description refers to a device that is capable of
seeking, the application shall either perform an fflush(), or the stream
shall be closed.

For the second handle:

    If any previous active handle has been used by a function that
explicitly changed the file offset, except as required above for the
first handle, the application shall perform an lseek() or fseek() (as
appropriate to the type of handle) to an appropriate location.

If the active handle ceases to be accessible before the requirements on
the first handle, above, have been met, the state of the open file
description becomes undefined. This might occur during functions such as
a fork() or _exit().

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--TJrX8LL8tj0njctvOsdGO9fVrHmw5jHio
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJS1V2WAAoJEKeha0olJ0NqCDQH/RA2r8LjDDbI35A0+nkLb8pH
9BCqSY0X5fwsi7i6ZL3NuO4rC483h0gpPAko0EX5EQ4wwLkcjNCIuUaYyCSulSmc
ObjNrgcttf51PDQXKUa/v3BXcXDrRYD3cSR8sLFgCSi35mI1B14tfAHxmVfv0wiP
8CGk4MJU1yyVo7zA3jFXjiC5E9pa5jxLK0/gzB5Z5cC9LBkLHYewl9NcfnLsg21z
tUcAYWCsY4iVN7SYeFATuSBhsrsOS7wDqqWkNnEvtQt+hnJ1OMb5B4rYqjeAtvoN
GbGPIvzftApcv2gbfjC1sMdS8hVHo9f6K0tL/ydVrTXAC+9rfrh6zdESP9qOxZo=
=bqfZ
-----END PGP SIGNATURE-----

--TJrX8LL8tj0njctvOsdGO9fVrHmw5jHio--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019