From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87177 invoked by alias); 1 Jul 2015 20:12:35 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 87167 invoked by uid 89); 1 Jul 2015 20:12:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: limerock04.mail.cornell.edu Received: from limerock04.mail.cornell.edu (HELO limerock04.mail.cornell.edu) (128.84.13.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Jul 2015 20:12:33 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id t61KCUfZ026899 for ; Wed, 1 Jul 2015 16:12:31 -0400 Received: from [10.128.132.16] (dhcp-gs-1040.eduroam.cornell.edu [10.128.132.16]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id t61KCUhD028610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Jul 2015 16:12:30 -0400 Message-ID: <559449AF.9010804@cornell.edu> Date: Wed, 01 Jul 2015 20:12:00 -0000 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1 References: <20150626141437.GV31223@calimero.vinschen.de> <558D62D7.8010709@cornell.edu> <20150626153647.GX31223@calimero.vinschen.de> <558D8409.2000400@cornell.edu> <20150626200512.GA30636@calimero.vinschen.de> <558DD1F3.4010301@cornell.edu> <20150627145259.GB23036@calimero.vinschen.de> <20150630195547.GG2918@calimero.vinschen.de> <5592F86E.8070803@cornell.edu> <20150701104748.GH2918@calimero.vinschen.de> <20150701135749.GN2918@calimero.vinschen.de> In-Reply-To: <20150701135749.GN2918@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00012.txt.bz2 On 7/1/2015 9:57 AM, Corinna Vinschen wrote: > On Jul 1 12:47, Corinna Vinschen wrote: >> On Jun 30 16:13, Ken Brown wrote: >>> On 6/30/2015 3:55 PM, Corinna Vinschen wrote: >>>> On Jun 27 16:52, Corinna Vinschen wrote: >>>>> On Jun 26 18:28, Ken Brown wrote: >>>>>> On the other hand, emacs doesn't really make a full recovery. For example, >>>>>> if I try to call a subprocess (e.g., 'C-x d' to list a directory), I get a >>>>>> fork error: >>>>>> >>>>>> Debugger entered--Lisp error: (file-error "Doing vfork" "Resource >>>>>> temporarily unavailable") >>>>> [...] >>>> Just FYI, I don't know yet what happens exactly, but this has nothing >>>> to do with the alternate stack. The child process fails with a status >>>> code 0xC00000FD, STATUS_STACK_OVERFLOW. Which is kind of weird, given >>>> that the stack overflow has been averted by calling siglongjmp. >>>> >>>> I have a hunch. The stack state in the parent is so that TEB::StackLimit >>>> points into the topmost guard area which, when poked into, triggers the >>>> stack overflow exception. When forking, Cygwin performs exactly this: >>>> It pokes into the stack to push the guard page out of the way, thus >>>> causing the stack memory to be commited, which in turn allows to copy >>>> the stack content from parent to child. >>>> >>>> Ok, I'm not sure if I can debug this soon, but at leats it's not >>>> related to sigaltstack handling nor is it a regression. >>> >>> Thanks for the info, that's good to know. Just out of curiosity, were you >>> able to modify your testcase for this, or did you test with emacs? >> >> I just added a fork call to my testcase right after the last printf. > > My hunch was correct, apparently. I changed the way the stack info > is set up for the child so only the actually used part of the stack is > prepared for the stack copy in the child. This not only avoids the > stack overflow in the child, it should shave a few nanoseconds from > the time a fork takes ;) > > I uploaded new developer snapshots to https://cygwin.com/snapshots/ and > I'm just building and uploading a new test release. > > Please give it another try. That fixes it. Thanks! Ken -- 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