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=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Mon, 6 Jul 2015 16:45:55 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.4
Message-ID: <20150706144555.GR2918@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <announce.20150705213417.GH2918@calimero.vinschen.de> <5599E4C5.1010109@cornell.edu> <20150706100158.GJ2918@calimero.vinschen.de> <559A7F74.1000402@cornell.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--