X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=default; b=qMPGZFQ40BRGrVs9zJLjYeu8an5KWwK1LebEPOvqKHL pZDHqP32ziiYBeK7kdRly/pwdtypRTPn0+VjS9avLfGHra3KNNTuGCnCeUtU3mqD ZvTNNpShbYZksNIcgmuGLW6BdH0MMgreL2+EpRlM1EfdeHzsyCwl5l0lAZ3FCqps = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=073I+8CAK/1x2167k/9Uk/VnT4A=; b=c8x657T+fL3giXMNV EajHrk9xt3Y5UtxihT8g8YKnl8p7E5y7Ypcwif2fdh0Pvltkt+ZbUMUnDB+0YkJz 4cxpLulZeJ2HKoKQsiDQI49TcZRyJkH7qQWqVktAKRbKCt0gvNKbP6EGLZqAHCgW rqbn5pmiZBKf+wBbYqjTpf4obQ= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail.lysator.liu.se Message-ID: <52D63CE2.9060308@lysator.liu.se> Date: Wed, 15 Jan 2014 08:46:42 +0100 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54 References: <831845 DOT 98759 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com> <52D55D96 DOT 8070407 AT redhat DOT com> <946338 DOT 89157 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2014-01-15 05:53, Lord Laraby wrote: > On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote: >> In message <52D55D96 DOT 8070407 AT redhat DOT com> you write: >>> >>> Your program may be violating POSIX, which would trigger undefined behavior. >>> >>> Quoting POSIX: >>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05 >>> >> >> [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 -- 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