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=na0JrbrRb+VfQkBjCjwLaIYlPQIvGi04mQIOsVDTWWV
	a0tnQfL5ogxzDPNO6B/0k6aMBRdkSvriI4B44D0FpBRBNTJArSqG1L/YMravPfO2
	Nek8F1bcvZNDPgbOT6ZmCG4lTz39rzxTNWwBJNyT+qawsDkoNV0syK41nC76o+CQ
	=
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=l+E7atn+NxiwTnD3+vgIgj7Nun4=; b=SpqIOdhnnrWqQ7c2H
	2jSR3Xs0JxiHtz4yDSeKPgLiyfvXp8NLwjNDZWeDGU0Tw5/ZZhQnXAvsT02JUY4M
	/8k2sAdKcdsQ1DzyPgsXlqUaCGc4ihMKf2J1G3QPDIOiuEgOCmzViad4xrOyLk4j
	R+H63NNJHNqNMSUhSHiUVZgMjc=
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=-0.8 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: limerock01.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Message-ID: <559AA4C8.30309@cornell.edu>
Date: Mon, 06 Jul 2015 11:54:48 -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
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4
References: <announce DOT 20150705213417 DOT GH2918 AT calimero DOT vinschen DOT de> <5599E4C5 DOT 1010109 AT cornell DOT edu> <20150706100158 DOT GJ2918 AT calimero DOT vinschen DOT de> <559A7F74 DOT 1000402 AT cornell DOT edu> <20150706144555 DOT GR2918 AT calimero DOT vinschen DOT de>
In-Reply-To: <20150706144555.GR2918@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
> Does emacs call setrlimit by any chance?

Yes, that's the problem.  The initialization code contains essentially the 
following:

if (!getrlimit (RLIMIT_STACK, &rlim))
     {
       long newlim;
       /* Approximate the amount regex.c needs per unit of re_max_failures.  */
       int ratio = 20 * sizeof (char *);
       /* Then add 33% to cover the size of the smaller stacks that regex.c
	 successively allocates and discards, on its way to the maximum.  */
       ratio += ratio / 3;
       /* Add in some extra to cover
	 what we're likely to use for other reasons.  */
       newlim = re_max_failures * ratio + 200000;
       if (newlim > rlim.rlim_max)
	{
	  newlim = rlim.rlim_max;
	  /* Don't let regex.c overflow the stack we have.  */
	  re_max_failures = (newlim - 200000) / ratio;
	}
       if (rlim.rlim_cur < newlim)
	rlim.rlim_cur = newlim;

       setrlimit (RLIMIT_STACK, &rlim);
     }

If I disable that code, the problem goes away: rlim_cur is set to the expected 
0x7fd000 in handle_sigsegv, and emacs recovers from the stack overflow.

I think I probably should disable that code on Cygwin anyway, because there's 
simply no need for it.  Some time ago I discovered that the default 2MB stack 
size was not big enough for emacs on Cygwin, and I made emacs use 8MB instead. 
So there's no need to enlarge it further.

> Btw., *if* emacs calls setrlimit and then expects getrlimit to return
> the *actual* size of the stack, rather than expecting that rlim_cur is
> just a default value when setting up stacks, it's really doing something
> borderline.
>
> There's simply *no* guarantee that a stack can be extended to this size.
> Any mmap() call could disallow growing the stack beyond its initial
> size.  Worse, on Linux you can even mmap so that the stack doesn't
> grow to the supposed initial maximum size at all.  The reason is that
> Linux doesn't know the concept of "reserved" virtual memory, but the
> stack is initially not commited in full either.
>
> If you want to know how big your current stack *actually* is, you can
> utilize pthread_getattr_np on Linux and Cygwin, like this:
>
> #include <pthread.h>
>
>    static void
>    handle_sigsegv (int sig, siginfo_t *siginfo, void *arg)
>    {
>      pthread_attr_t attr;
>      size_t stacksize;
>
>      if (!pthread_getattr_np (pthread_self (), &attr)
> 	&& !pthread_attr_getstacksize (&attr, &stacksize))
>        {
> 	beg = stack_bottom;
> 	end = stack_bottom + stack_direction * stacksize;
>
> 	[...]
>
> Unfortunately this is non-portable as well, as the trailing _np denotes,
> but at least there *is* a reliable method on Linux and Cygwin...

Thanks.  That fixes the problem too, even with the call to setrlimit left in. 
I'll report this to the emacs developers.

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