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
pgp1WTMntC3ap.pgp
Description: PGP signature
