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 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. > > 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp2YgK26KYwl.pgp
Description: PGP signature
