public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
Date: Wed, 01 Jul 2015 20:12:00 -0000	[thread overview]
Message-ID: <559449AF.9010804@cornell.edu> (raw)
In-Reply-To: <20150701135749.GN2918@calimero.vinschen.de>

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

  reply	other threads:[~2015-07-01 20:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-20 21:15 Corinna Vinschen
2015-06-21 18:47 ` Ken Brown
2015-06-22 11:08   ` Corinna Vinschen
2015-06-26 11:12     ` Corinna Vinschen
2015-06-26 12:02       ` Ken Brown
2015-06-26 14:14         ` Corinna Vinschen
2015-06-26 14:34           ` Ken Brown
2015-06-26 15:36             ` Corinna Vinschen
2015-06-26 16:55               ` Ken Brown
2015-06-26 20:10                 ` Corinna Vinschen
2015-06-26 20:26                 ` Corinna Vinschen
2015-06-26 22:28                   ` Ken Brown
2015-06-27 14:53                     ` Corinna Vinschen
2015-06-30 19:55                       ` Corinna Vinschen
2015-06-30 20:13                         ` Ken Brown
2015-07-01 10:47                           ` Corinna Vinschen
2015-07-01 13:57                             ` Corinna Vinschen
2015-07-01 20:12                               ` Ken Brown [this message]
2015-07-02  2:10                                 ` Ken Brown
2015-07-02 12:13                                   ` Corinna Vinschen
2015-07-02 12:20                                     ` Corinna Vinschen
2015-07-02 19:25                                       ` Ken Brown
2015-07-03 10:47                                         ` Corinna Vinschen
2015-07-03 10:50                                           ` Corinna Vinschen
2015-07-03 13:09                                           ` Ken Brown
2015-07-14 19:10                                             ` Ken Brown
2015-07-14 19:16                                               ` Corinna Vinschen
2015-07-14 22:19                       ` Eric Blake
2015-07-15  2:21                         ` Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559449AF.9010804@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).