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:

> 	while( fgets(buf, sizeof(buf), fp) ) {
> 		++i;
> 
> 		if(sscanf(buf, "%s %s", infile, outfile) != 2) {

> 
> 		switch (fork()) {
> 			

> 			case 0:
> 				fprintf(stderr, "child\n"); fflush(stderr);
> 				exit(0);

Your program violates POSIX, and triggers undefined behavior.  Add an
fflush(NULL) prior to the fork(), and that should avoid the infloop.

====
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05

> 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.)

Let's label our two handles: Handle 1 is the parent's handle, as well as
the lone handle that existed pre-fork.  Handle 2 is the child's handle.

>
> 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.

But the handle is a stream, not a file descriptor, so this is not met.

>
>     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.

The code isn't calling close(fileno(fp)), so this is not met.

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

fp is buffered, so this is not met.

>     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.

fp is not line buffered, so this is not met.

>
>     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.

fp is not open for writing, so this is not met.

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

fp is not at EOF, so this is not met.

>
>     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.

The application did not call fflush(fp) (or fflush(NULL)), and the
stream was not closed prior to fork, so this is not met.

>
> 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.

The previous active handle was used to change offset (by fgets), but
none of the requirements on the first handle were met, and we fail to
fseek() on the second handle.  Therefore, the fact that exit() calls
fflush() and changes the offset of the fd, leading to an infloop in the
parent, is a result of the bug in the program violating the POSIX
constraints on active handle manipulation.

>
> 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