This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]