FILE buffer flush on fork+exec

[Noob]

Hello,

In the context of fork+exec

Suppose the parent holds a non-empty FILE buffer.
It forks, so the child gets a copy of the data.
If the child exec, does these data get flushed to the underlying fd?

If the exec fails, then the child exits, then I think the data are
indeed flushed to the underlying fd?

Regards.

[Joe Pfeiffer]

Noob <ro...@127.0.0.1> writes:

> In the context of fork+exec
>
> Suppose the parent holds a non-empty FILE buffer.
> It forks, so the child gets a copy of the data.
> If the child exec, does these data get flushed to the underlying fd?

No. You would need to fflush(), fclose(), or similar to flush the
buffer.

> If the exec fails, then the child exits, then I think the data are
> indeed flushed to the underlying fd?

Yes.

But the real answer here is "don't do that. Flush your buffers before
you call fork()".

[Kaz Kylheku]

On 2016-04-21, Noob <ro...@127.0.0.1> wrote:
> Hello,
>
> In the context of fork+exec
>
> Suppose the parent holds a non-empty FILE buffer.
> It forks, so the child gets a copy of the data.
> If the child exec, does these data get flushed to the underlying fd?
>
> If the exec fails, then the child exits, then I think the data are

Contrary to your belief, the child will not exit if exec fails; the
exit function just returns, and the child keeps executing whatever
code follows. If you want an immediate exit upon a failed
exec, you must code that yourself.

> indeed flushed to the underlying fd?

It's great that you figured this out on your own, but the issue
is decades old and Unix has a solution for it: the _exit function.

[Joe Pfeiffer]

Kaz Kylheku <545-06...@kylheku.com> writes:

> On 2016-04-21, Noob <ro...@127.0.0.1> wrote:
>> Hello,
>>
>> In the context of fork+exec
>>
>> Suppose the parent holds a non-empty FILE buffer.
>> It forks, so the child gets a copy of the data.
>> If the child exec, does these data get flushed to the underlying fd?
>>
>> If the exec fails, then the child exits, then I think the data are
>
> Contrary to your belief, the child will not exit if exec fails; the
> exit function just returns, and the child keeps executing whatever

exec?

> code follows. If you want an immediate exit upon a failed
> exec, you must code that yourself.

FWIW, I read his question as the program decides to exit after the
exec() failed, not that the exec() failure terminated his program. You
are of course correct that what the program does after a return from
exec() is up to the program.

[Noob]

On 21/04/2016 19:08, Joe Pfeiffer wrote:

I am investigating a bug in a third-party program.

That program has several FILE buffers open, writing logs
to different files, and it fork/execs a lot to run many
diagnostic sub-programs.

(At least) one of the logs is "corrupted" in that
1) it contains many duplicated lines
2) some expected lines are missing

Looking more closely at the fork/exec part, I can confirm that
the child calls exit(errno); when the exec() fails.

So it would seem that problems would occur only when exec fails?
If exec succeeds, we wouldn't flush the FILE buffer twice...
Hmmm, I am somewhat stumped.

Regards.

[Noob]

Another solution would be to not use FILE buffers.

Since this program is meant to run only on Linux, I think
that would make sense.

I'll suggest the _exit() function to the author.

Regards.

[Casper H.S. Dik]

Joe Pfeiffer <pfei...@cs.nmsu.edu> writes:

>> If the exec fails, then the child exits, then I think the data are
>> indeed flushed to the underlying fd?

>Yes.

Unless you use _exit() in execing in the child instead of exit().

>But the real answer here is "don't do that. Flush your buffers before
>you call fork()".

Which is why the standards has "fflush(NULL)" which flushes all
your buffers.

Casper

[boon]

On Thursday, April 21, 2016 at 7:55:25 PM UTC+2, Kaz Kylheku wrote:
> On 2016-04-21, Noob <ro...@127.0.0.1> wrote:
> > Hello,
> >
> > In the context of fork+exec
> >
> > Suppose the parent holds a non-empty FILE buffer.
> > It forks, so the child gets a copy of the data.
> > If the child exec, does these data get flushed to the underlying fd?
> >
> > If the exec fails, then the child exits, then I think the data are
>
> Contrary to your belief, the child will not exit if exec fails; the
> exit function just returns, and the child keeps executing whatever
> code follows. If you want an immediate exit upon a failed
> exec, you must code that yourself.

This is why we can often read such code with comment:

execv(...);
/* Should never get there */
exit(EXIT_FAILURE);

[Kaz Kylheku]

The standard has a feature for the sake of a function that
the standard doesn't have? :)

[Barry Margolin]

In article <201604220...@kylheku.com>,

It has this feature just in case you run your C program on an OS that
has a function that forks processes.

I know it's unlikely .... :)

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Joe Pfeiffer]

The program would have to be doing something *really* weird (as in,
nothing comes to mind as I'm typing) for an extra fflush() before calls
to fork() to cause a problem. So I'd start by putting a fflush(NULL)
before all the fork() calls and see what happens.

[Kaz Kylheku]

On 2016-04-22, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <201604220...@kylheku.com>,
> Kaz Kylheku <545-06...@kylheku.com> wrote:
>
>> On 2016-04-22, Casper H.S Dik <Caspe...@OrSPaMcle.COM> wrote:
>> > Joe Pfeiffer <pfei...@cs.nmsu.edu> writes:
>> >
>> >>> If the exec fails, then the child exits, then I think the data are
>> >>> indeed flushed to the underlying fd?
>> >
>> >>Yes.
>> >
>> > Unless you use _exit() in execing in the child instead of exit().
>> >
>> >>But the real answer here is "don't do that. Flush your buffers before
>> >>you call fork()".
>> >
>> > Which is why the standards has "fflush(NULL)" which flushes all
>> > your buffers.
>>
>> The standard has a feature for the sake of a function that
>> the standard doesn't have? :)
>
> It has this feature just in case you run your C program on an OS that
> has a function that forks processes.

Right, and ISO C just *loves* making behaviors defined!

So the idea of leaving fflush(NULL) undefined and allowing POSIX to
define it would be unthinkable.

[Barry Margolin]

In article <20160422...@kylheku.com>,

To their credit, they did that with fflush(stdin). POSIX doesn't define
it, but I think Windows does (I assume, since I frequently see it in
programs that Doze users post to SO).

[Noob]

On 22/04/2016 20:40, Barry Margolin wrote:

> To their credit, they did that with fflush(stdin). POSIX doesn't define
> it, but I think Windows does (I assume, since I frequently see it in
> programs that Doze users post to SO).

According to the Linux man page:
http://man7.org/linux/man-pages/man3/fflush.3.html

For input streams associated with seekable files (e.g., disk files,
but not pipes or terminals), fflush() discards any buffered data that
has been fetched from the underlying file, but has not been consumed
by the application.

Regards.

[Scott Lurndal]

According to POSIX:

http://pubs.opengroup.org/onlinepubs/007908799/xsh/fflush.html

[Noob]

On 25/04/2016 16:00, Scott Lurndal wrote:

You might need to update your bookmarks.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html

Regards.