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


On Jan 15 10:28, tednolan@bellsouth.net wrote:
> 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..

Just for completeness:  I can test on Linux, but not on FreeBSD and
Solaris.  Does the testcase also work as expected on both of them,
after you added fclose to the child?  On Linux it does.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgphbitv8Wjdj.pgp
Description: PGP signature


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