Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54

[Eric Blake <eblake at redhat dot com>]

On 01/13/2014 09:06 AM, tednolan@bellsouth.net wrote:
> Hello,
> 
> I'm running:
> 
> 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
> 
> on a 64 bit Win7 system.
> 
> 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#tag_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().

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

Attachment: signature.asc
Description: OpenPGP digital signature