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 :} > In view of what Ben said, I don't really care about this from the emacs > point of view. I mention it only in case it's useful to you for testing the > alternate stack. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpKkbEpwhnsD.pgp
Description: PGP signature
