This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


In message <52D63CE2.9060308@lysator.liu.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.8070407@redhat.com> you write:
>>>>
>>>> Your program may be violating POSIX, which would trigger undefined behavio
>r.
>>>>
>>>> Quoting POSIX:
>>>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_0
>5
>>>>
>>>
>>> [long quote elided]
>>>
>>> Yikes!  That's pretty impenatrable.  And if it says what I think it says,
>>> 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.
>> 
>> 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 implementation
>defined, so I'm not sure it will help in all situations.
>
>Cheers,
>Peter

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? -:)

FWIW, FreeBSD, Linux and Solaris all compile and run the test program
with the behavoir I expect..


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]