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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=wmzQG8IUgcDYlk7i5nt2k2e0NxrnI3g/kaHd1/qbnQeedRRqj6BMH
	Sico72gNdz3i8rGKKjN5flPyY76FDqdJkoHcyDOimDPgPndnEOHHd54SguZs2YPe
	sZx376yRy/NoVzTDBpNXyjPQTfuyZt8Z2QJGPqaK76XSEfCaTY9lGo=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=whCu3GtS5GkRn/NivDyKM0Qj5Hg=; b=Ky4/EGudN5OeBx4HOBc3D9hTN8vj
	7S1ELBfXduc4kjBJsd4eDVtVakOHrH/a2bqL0RTgRVAkHdx9pjRy8l0oFcjUMhLD
	sxAYh16iRoJt7VnNlTgPahEpSuxgMCDBM3P5cNM8feaQ+0HVe+nFYFUN4a+0SbYl
	sGBrkQhFS5VKuPQ=
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=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Mon, 6 Jul 2015 18:34:24 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4
Message-ID: <20150706163424.GV2918@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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> <559AA4C8 DOT 30309 AT cornell DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="nCRcqX7cEx7rr7Pe"
Content-Disposition: inline
In-Reply-To: <559AA4C8.30309@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

--nCRcqX7cEx7rr7Pe
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jul  6 11:54, Ken Brown wrote:
> On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
> >Does emacs call setrlimit by any chance?
>=20
> Yes, that's the problem.  The initialization code contains essentially the
> following:
>=20
> if (!getrlimit (RLIMIT_STACK, &rlim))
>     {
>       long newlim;
>       /* Approximate the amount regex.c needs per unit of re_max_failures=
.  */
>       int ratio =3D 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 +=3D ratio / 3;
>       /* Add in some extra to cover
> 	 what we're likely to use for other reasons.  */
>       newlim =3D re_max_failures * ratio + 200000;
>       if (newlim > rlim.rlim_max)
> 	{
> 	  newlim =3D rlim.rlim_max;
> 	  /* Don't let regex.c overflow the stack we have.  */
> 	  re_max_failures =3D (newlim - 200000) / ratio;
> 	}
>       if (rlim.rlim_cur < newlim)
> 	rlim.rlim_cur =3D newlim;
>=20
>       setrlimit (RLIMIT_STACK, &rlim);
>     }

Ok.

> 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 defau=
lt
> 2MB stack size was not big enough for emacs on Cygwin, and I made emacs u=
se
> 8MB instead. So there's no need to enlarge it further.

Yes, that probably makes sense.  The computed expression above has
another problem on Windows:  The stacksize is always a multiple of 64K
due to the dreaded allocation granularity.

> >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 =3D stack_bottom;
> >	end =3D 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...
>=20
> Thanks.  That fixes the problem too, even with the call to setrlimit left
> in. I'll report this to the emacs developers.

Excellent, thanks for testing this!


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--nCRcqX7cEx7rr7Pe
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVmq4QAAoJEPU2Bp2uRE+gW5oP/AsDJFrEEw84HdhxP5fJKLOh
wtGsDDiLGgaJ0If9GjlTGlzfS+3+6krhgwAm6W+nYyBcNRgeaMMnDuQ84TwkPEZV
wZA1p84F2M3FjQy7WZjvATGgNyH6hQvXawJwgjEXCnt4tHzRrWa3FUK3oez74ScB
fGMjGjNeL3SUStaI7Wo6dMkfsknvhdAhey7RS7K2IrHnjhZbiEx9QXq6thBS12py
3jqrRhr+aO2e6YMDsGhoL7GYlAjEyTAmCvgStqRiqmy9dJp5vL0rGNPoyERB7ovC
MNTNmq00i3Ij/DX87C4VW17JnPncciLa7sAsHCFy7pG1cWkk0Qceh+Qy7bgkco60
u1FEWoVSrIbgQXYCRh+pzAThXl963Nj+7r3hbQc8dZVt5M6L4CCs+x1iF/fjCJGL
P27e2X/fIE3SH7lbWkwFLcssgrTq1t0PVXgkkdhigLSoeDxDZ29W+EF8ZdOEQvNO
Niq2H3gkSHch/m8XkL2cIVClMSR7mzMlx4tnpS1XiOVbjkiA9HtlTGWUBwyrtRZw
YoiFwOtTHJDizy+w20chL2y9Ao5QOq8jDx81+1RF3wndRqneeUnnYGFyKL5cFZCU
6ACkDBlbrNUmJD3wCm1T69jDutEkU6gUbv3E6OBHzJxuhGl6zXbROOMvQ3r9H66i
XR3gOCX4bdo6ozwIqdek
=CgnP
-----END PGP SIGNATURE-----

--nCRcqX7cEx7rr7Pe--