X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=hHY2evNxMnXqDRs+jPJPOVPmiwBmpah+5bGwdwKy+M4
	fZoIOpr7Tg9OHuBSKu1wZ/cbTn7p/yq9Y3Nzra0XECudN5gewdaJbx+Kzrn/4ptA
	GFNnis4SwKCw6CFLvKgOxkmKFM5eJ8w63/BeyxC+5aFuMkrNSxJTjFbekF7g4xKg
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=QQx1Zu/2z0Pm2kjvYDbT6rMElhA=; b=C9RVQv2UUOgJqz89X
	DrEIIvFbLqYOuvozj5jIVc2c612kWjZBsIPqtN09txQIwRdKooVwVSoMjURL45cW
	Pr5hMJC+aXFJwgEs9kwYdOhm7pHjxRqzCJOIaGK5DT7xnAqqztAMn/1LHFIct5Vj
	dhltF/Rwd0xA9VfwwFC9X4N0yU=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.1 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	limerock03.mail.cornell.edu
X-CornellRouted:	This message has been Routed already.
Message-ID:	<558DD1F3.4010301@cornell.edu>
Date:	Fri, 26 Jun 2015 18:28:03 -0400
From:	Ken Brown <kbrown AT cornell DOT edu>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com, Ben Woodard <woodard AT redhat DOT com>
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
References:	<announce DOT 20150620205512 DOT GA28301 AT calimero DOT vinschen DOT de> <558706D5 DOT 1020508 AT cornell DOT edu> <20150622110835 DOT GE28301 AT calimero DOT vinschen DOT de> <20150626111249 DOT GS31223 AT calimero DOT vinschen DOT de> <558D3F4C DOT 6090207 AT cornell DOT edu> <20150626141437 DOT GV31223 AT calimero DOT vinschen DOT de> <558D62D7 DOT 8010709 AT cornell DOT edu> <20150626153647 DOT GX31223 AT calimero DOT vinschen DOT de> <558D8409 DOT 2000400 AT cornell DOT edu> <20150626200512 DOT GA30636 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20150626200512.GA30636@calimero.vinschen.de>
X-IsSubscribed:	yes

On 6/26/2015 4:05 PM, Corinna Vinschen wrote:
>
> [CC Ben, please keep him on the CC in replies.  Thank you]
>
>
> Hi Ken,
>
> On Jun 26 12:55, Ken Brown wrote:
>> Hi Corinna,
>>
>> On 6/26/2015 11:36 AM, Corinna Vinschen wrote:
>>> Thanks.  Another question:  How does emacs compute stack_bottom?
>>
>> Very near the beginning of main() it does the following:
>>
>>    char stack_bottom_variable;
>> [...]
>>    /* Record (approximately) where the stack begins.  */
>>    stack_bottom = &stack_bottom_variable;
>
> Thank you.
>
> I created an STC with your code snippets and it now works for me
> (attached for reference).
>
> First problem was the return value of getrlimit(RLIMIT_STACK).
>
> Second problem is emacs.  The check for an offset of the offending
> address in si_addr being less than 16K (STACK_DANGER_ZONE) is
> non-portable, putting it mildly.  This might work on 32 bit Cygwin (I
> didn't test that), but the value is too low for 64 bit Cygwin.  With
> STACK_DANGER_ZONE == 32K the handler works as desired on 64 bit Cygwin.
> Part of the reason is probably the _cygtls area of 12K reserved on each
> thread's stack, which moves the address of &stack_bottom_variable to a
> pretty low value right from the start.  Another the size of the guard
> page area on the main thread (16K).
>
> I had a brief email exchange with a collegue of mine.  Ben allowed me to
> quote him, so here are the important snippets of his replies:
>
> - Rlimits are an old way of doing a job and they were to a certain
>    extent tied up in the pre-thread world of unix processes.  rlimits
>    have never been fully implemented on linux with a way that reproduces
>    the unix way in the pre-thread era. rlimits have become a bit of a
>    historical legacy and are there for posix compliance and code
>    compatibility. The posix language was designed to be vague enough that
>    all implementations could be made to conform.
>
> - Rather than making the system implementation conform to some
>    unspecified behavior, I think it might be a wise idea to fix emacs
>    instead. Looking at the code fragment you posted below(*), I’m not
>    entirely convinced that the code would operate as intended on modern
>    Linux or Unix. Given that, it may be better to make an implementation
>    which does something like the current behavior was intended to do or
>    better yet just remove it as a likely latent bug.
>
> (*) Emacs' handle_sigsegv function.
>
> Of course, for testing purposes this is still nice to have, so thank you
> for this test, I really appreciate it.
>
> 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")
   call-process("ls" nil nil nil "--dired")
   dired-insert-directory("/home/kbrown/src/emacs/32build/" "-al" nil nil t)
   dired-readin-insert()
   dired-readin()
   dired-internal-noselect("~/src/emacs/32build/" nil)
   dired-noselect("~/src/emacs/32build/" nil)
   dired("~/src/emacs/32build/" nil)
   funcall-interactively(dired "~/src/emacs/32build/" nil)
   call-interactively(dired nil nil)
   command-execute(dired)

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.

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

- Raw text -