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=fWR4rJhRjCcnryACRWUVeSvQejG+UIFmlw59JVNcVLLW7DnyzML9g
	zGVvuiPFG08ck1xMcZAQ8xXhfIqRqJadEdh6i4Tkl1W4LHR9lKvnbk0iDIAjuRzt
	Y7AVo+KmWA2u6RzcI47ueuHRGzoCvKpkyc6xPbim2o4ek68memCiLI=
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=moW+sQsWwqBi0kN2cfaNmZA1rlI=; b=KNeX29ewDXKpTl5MSLTN7+6M3k1e
	D+KGZj2/t9TEl5mv9f4wVSH9vJEXWxBFDtuePd4hIqMP4XwWOVTRf21Sc2jJA+nf
	+ymEvS+pNfMPv6JIeHJaFQM4ZxIceeias4B6lJnDpIKgSkz+zARyf4ygymMJIwXC
	CfQwA7NDb5W3a7s=
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: Fri, 26 Jun 2015 17:36:47 +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.1
Message-ID: <20150626153647.GX31223@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="twKjCw1/F6C/WBH6"
Content-Disposition: inline
In-Reply-To: <558D62D7.8010709@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

Hi Ken,

On Jun 26 10:33, Ken Brown wrote:
> On 6/26/2015 10:14 AM, Corinna Vinschen wrote:
> >On Jun 26 08:02, Ken Brown wrote:
> >>On 6/26/2015 7:12 AM, Corinna Vinschen wrote:
> >Thank you.  I'll try to test this in the next couple of days.  One hint
> >and one question:
> >
> >>The signal handler:
> >>
> >>/* Attempt to recover from SIGSEGV caused by C stack overflow.  */
> >>static void
> >>handle_sigsegv (int sig, siginfo_t *siginfo, void *arg)
> >>{
> >>   /* Hard GC error may lead to stack overflow caused by
> >>      too nested calls to mark_object.  No way to survive.  */
> >>   if (!gc_in_progress)
> >>     {
> >>       struct rlimit rlim;
> >>
> >>       if (!getrlimit (RLIMIT_STACK, &rlim))
> >
> >This getrlimit probably won't work as desired.  I just had a quick look
> >how this request is handled.  It will return the size of the alternate
> >stack while running the signal handler, rather than the size of the
> >initial thread's stack as required by POSIX.  This definitely needs
> >fixing.
> >
> >>	{
> >>	  enum { STACK_DANGER_ZONE =3D 16 * 1024 };
> >>	  char *beg, *end, *addr;
> >>
> >>	  beg =3D stack_bottom;
> >>	  end =3D stack_bottom + stack_direction * rlim.rlim_cur;
> >>	  if (beg > end)
> >>	    addr =3D beg, beg =3D end, end =3D addr;
> >>	  addr =3D (char *) siginfo->si_addr;
> >>	  /* If we're somewhere on stack and too close to
> >>	     one of its boundaries, most likely this is it.  */
> >>	  if (beg < addr && addr < end
> >>	      && (addr - beg < STACK_DANGER_ZONE
> >>		  || end - addr < STACK_DANGER_ZONE))
> >>	    siglongjmp (return_to_command_loop, 1);
> >>	}
> >>     }
> >>
> >>   /* Otherwise we can't do anything with this.  */
> >>   deliver_fatal_thread_signal (sig);
> >>}
> >>
> >>The code to set up the signal handler on the alternate stack:
> >>
> >>static bool
> >>init_sigsegv (void)
> >>{
> >>   struct sigaction sa;
> >>   stack_t ss;
> >>
> >>   stack_direction =3D ((char *) &ss < stack_bottom) ? -1 : 1;
> >>
> >>   ss.ss_sp =3D sigsegv_stack;
> >>   ss.ss_size =3D sizeof (sigsegv_stack);
> >                  ^^^^^^^^^^^^^^^^^^^^^^^
> >
> >What's that size in bytes?
>=20
> SIGSTKSZ

Thanks.  Another question:  How does emacs compute stack_bottom?


Corinna

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

--twKjCw1/F6C/WBH6
Content-Type: application/pgp-signature

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

iQIcBAEBCAAGBQJVjXGPAAoJEPU2Bp2uRE+gcIAP+QGy5jYS3AhJZCQOMbWonXpr
0sQ6m/ST78iHhEWI23aFyQehmlDbk7RPWcmIvpv0pG4pNOg02WiBubGaGWu+oILH
HCbND5JxItAS9vyiFMICL1UsaL77y1jSouu46duD5vYr5159WJnMBZQBQEmaz1sN
p0tNTpFOnNLS17Jlu8PAvbEvLRXhCwriy9TSVUIpDhHmHm7/Si8fkyFWjafz62ro
vByDjCt4PUV5A0M1SsEP4b5n7BvgKU9ujEnZ26mQpYlLBeKy/JSTRyzJ1Jauom+d
TcUsRKXsbPLwIFWQfFIZGqXtNJu4uATFejTOoTOkzfIlm/xPwOecB1gP9p2W1Wk2
hsSNiUzgC5pEOICfqAYq9r4R+NbE1S/R8m4lOG5jDwEEqwDOEvOg2z82d5LHdMPo
MTXj0itfY4ggPGlWXMqzJXXVFmwoW8jwf7b+tw7VCuzQ0WxT8i1bKJA+Mas4LJZh
ElHrn1dtPslfiO+0aPf7N+Irrt/o3fs9qAJ1RsWF6bcIIwkZu+paWkU8NNaQ6go1
OVOwaYSqsy9IPbGaO/DTBvBhF+IuS0A3eJpPxZ4y9f/KaC2Hdlm4/wtxPkG390o5
PgvFmsBC1+hiCQr6DCFIqHfMg+2Y3HVcwlMmq2UlGmb0VhsBOJqk06JpDNhoSDBR
o+W7uN/DF3pRLBNlRcNT
=nCRj
-----END PGP SIGNATURE-----

--twKjCw1/F6C/WBH6--