Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jun 27 16:52, Corinna Vinschen wrote:
> On Jun 26 18:28, Ken Brown wrote:
> > On 6/26/2015 4:05 PM, Corinna Vinschen wrote:
> > >As for getrlimit(RLIMIT_STACK), I changed that as outlined in my former
> > >mail in git.  On second thought, I also changed the values of
> > >MINSIGSTKSZ and SIGSTKSZ.  Instead of 2K and 8K, they are now defined
> > >as 32K and 64K.  The reason is that we then have enough space on the
> > >alternate stack to install a _cygtls area, should the need arise.
> > >
> > >I created new developer snapshots on https://cygwin.com/snapshots/
> > >Please give them a try.
> > >
> > >Remember to tweak STACK_DANGER_ZONE.  You'll have to rebuild emacs
> > >anyway due to the change to [MIN]SIGSTKSZ.
> > 
> > Hi Corinna and Ben,
> > 
> > It works now, in the sense that emacs doesn't crash, and it produces the
> > message "Re-entering top level after C stack overflow".  I tested both
> > 32-bit and 64-bit Cygwin.  My test consisted of evaluating the following in
> > the emacs *scratch* buffer:
> > 
> > (setq max-specpdl-size 83200000
> >       max-lisp-eval-depth 640000)
> > (defun foo () (foo))
> > (foo)
> > 
> > (The 'setq' is to override emacs's built-in protection against too-deeply
> > nested lisp function calls.)
> > 
> > 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")
> 
> The problem is probably that there are still resources in use which
> didn't get free'd.  I'll check next week if I can do anything about it.
> Ideally with a simple testcase than emacs :}

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.


Corinna

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

Attachment: pgpKrMQHf9bhs.pgp
Description: PGP signature