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=ZAlLBv0GW16G8Aw7lgEcbUmH/OF+80bQ+xL/fQ4Dmrg90vUuiv3D0
	PcHNoxOAN5c1Ldx9LIRtYTvtivmu/3g+AMLrQ2Bn84aQoSDeYgIAH7icUPTJ3+QQ
	3Y6yu4386pY1rJXlxFYutAtO3WbojrHTZUvMCkT/hsC36MgjEtYkPk=
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=6WNEPsLYWwakBGd8BadjWOGJ/cg=; b=UtJSobVwUjByvvHNCLFJHpIKKp1c
	PtD085S3+SC1PepEliwvwWv8L9bZsjGaynhL53oCofvmDQ/Z2evzGGgG2gYHdSZg
	Qupj/gzweJZPLRwpa4ZX7I8Dcws/Uy/s35E2ZvJQbSuI5g0p9ISY4DXk6sQDjyUW
	i8RKZot6B9uRE+Q=
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 16:45:55 +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: <20150706144555.GR2918@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="tzjrJU3+iJ6c5SNx"
Content-Disposition: inline
In-Reply-To: <559A7F74.1000402@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

Hi Ken,

On Jul  6 09:15, Ken Brown wrote:
> Hi Corinna,
>=20
> On 7/6/2015 6:01 AM, Corinna Vinschen wrote:
> >On Jul  5 22:15, Ken Brown wrote:
> >
> >I have no explanation for this.  What OS?  What does rlim_cur contain?
> >What does peflags -x print for this executable?
>=20
> I'm on W7 64-bit.  The problem seems to be that rlim_cur is too big.
>=20
> $ peflags -x ./emacs
> ./emacs: stack reserve size      : 8388608 (0x800000) bytes
>=20
> (gdb) p beg
> $3 =3D 0x82ca27 ""
> (gdb) p/x rlim.rlim_cur
> $2 =3D 0x850e80

Does emacs call setrlimit by any chance?  Otherwise, rlim_cur should be
set to

  0x800000 - 0x1000 (4K dead zone) - 0x2000 (8K guard page on W7 64)
  =3D=3D 0x7fd000.

> So there's overflow when end is computed:
>=20
> (gdb) p end
> $4 =3D 0xfffffffffffdbba7 <error: Cannot access memory at address 0xfffff=
ffffffdbba7>
>=20
> This doesn't happen when I run your testcase with the same 8MB stack size:
>=20
> $ peflags -x0x800000 ./sigalt.exe
> ./sigalt.exe: stack reserve size      : 8388608 (0x800000) bytes
>=20
> (gdb) p beg
> $1 =3D 0x82cabb ""
> (gdb) p/x rlim.rlim_cur
> $2 =3D 0x7fd000

... like this.

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...


Corinna

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

--tzjrJU3+iJ6c5SNx
Content-Type: application/pgp-signature

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

iQIcBAEBCAAGBQJVmpSjAAoJEPU2Bp2uRE+gDYUP/1diHO9swsMalbj5SDSzlIzl
RY/8590ks2pb0AFHrra/mdjTY/rAYeEJkp2PefGioGZ/faOIBZPpf860t8LyixaR
OraQYKoiaPYA+g+rH477U7+q/Hf0kbSzG2kd5wXumdIcIkqNfe+eErMCP3G40kcN
Wz3TUQm7LoE791xzPF8fye6upo4cKzt2zX7i+pjXIhqPilX4KJEcI+LHypH9mxOj
AS+YUu8z+YX+tl9Wp2QRnMPYDPQiy3e+yvPROGDxSK/fUs6u9TDKz3+KbQJkdNWV
PIVZY6uOjyfWGHZLPaak5Tsbbmqpl1u1tDKWaTjzIAdqZUACZdl+kA6UvQAXdL3c
8Sc7aBrpyvMJjOJRfyMOFNWSO5RnY8mFYnLRqsU+K9ad4HpGMMdjKI17g0o3jRam
ewlkvw7u9A0FF6+KpzaOXPHhLNYapBPL4Qsq0FeYT8OcrUyA32a0IMG2SsrStOKw
Q2S3BoFSi6CXMaIm3+2hhIAgxJDJH2p3B/1zOljZhmagC3lMfu87jLYA8hM9KVYf
PkUNPtA1GtJ+TAz/2pfPoB7hrcUwZUgywfXoKmUcVdSsG93+Q9lSaBzni96rwDC/
Br5U8Q9jV4S7CvHk+HW1oeiVs+DXUIuVQHkaGgbX21xn+7HiV5J6zrPtursQmNVc
/KtE7caj03ELWVGyt/Vh
=3uAc
-----END PGP SIGNATURE-----

--tzjrJU3+iJ6c5SNx--