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=vGQnv5n9XBxQMsGtXDt9KFJFmspHcdDP8JXESTNGzxw7JJKd4vK8X
	vxXecHAT6QuKCzfApOQyLxvbvFRsQjt4ka8FX5AglcUz17vYs7DfgwcnMcB44oyA
	MjDD+Q63IZyQG1p/U9XaBGbIGQuUaIh72u6yJebBV7twCe1zLKTLik=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Tue, 7 Jul 2015 17:49:16 +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: <20150707154916.GB2918@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> <20150706144555.GR2918@calimero.vinschen.de> <559AA4C8.30309@cornell.edu> <20150706163424.GV2918@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="qw1jpiGhEv1c2/gd"
Content-Disposition: inline
In-Reply-To: <20150706163424.GV2918@calimero.vinschen.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Jul  6 18:34, Corinna Vinschen wrote:
> On Jul  6 11:54, Ken Brown wrote:
> > On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
> > >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 denote=
s,
> > >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 le=
ft
> > in. I'll report this to the emacs developers.
>=20
> Excellent, thanks for testing this!

Uh oh.  We have a problem there.  This only worked accidentally, at least
on x86_64.  What happens is that pthread_getattr_np checks the validity
of the "attr" parameter and while doing so it may (validly) raise a SEGV.

Usually this SEGV is catched by a special SEH handler in Cygwin, which
is used to implement __try/__except blocks in Cygwin.  The validity
check returns the matching information "object uninitialized" to the
caller.

Not so here.  Since we're still in exception handling while running the
signal handler, another nested SEGV makes the OS kill the process without
calling any SEH exception handler on the way.

The problem is, there doesn't seem to be an elegant way around that on
x86_64.  From the application perspective you can just initialize the
pthread_attr_t to 0, as in

  pthread_attr_t attr =3D { 0 };

but that's ... unusual.  It's so unusual that nobody will ever think of
it.  The other way to "fix" this in the application itself is to call
pthread_getattr_np in the main() function, which works because we're not
running in the context of the exception handler.

The only solution inside Cygwin I found so far is this:

  Every myfault setup will have to capture the current thread context
  and set up a vectored continuation handler.  This handler will be
  called if no other exception handler feels responsible for an
  exception.  Fortunately it's called even while another exception is
  still handled.  The vectored handler then restores the thread context,
  just with tweaked instruction pointer.

What bugs me with this solution is not only that it looks rather
hackish, but also that it comes with a performance hit.  The fact
that every __try/__except block has to call RtlCaptureContext is
not exactly free of charge...

As you might have noticed, this has nothing to do with the alternate
stack.  It's just YA problem which cropped up during this testphase.


Oh well,
Corinna

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

--qw1jpiGhEv1c2/gd
Content-Type: application/pgp-signature

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

iQIcBAEBCAAGBQJVm/T8AAoJEPU2Bp2uRE+gSN4P/13iTDEichg95xWeP7Hz0vOa
SJtROZtRz/z5M4698VebRU/mF0a8zjXvpvQebGQ0TAR7m+2EpTr0ixCYChJ+PS+/
NUPaLubQmf7G/m5u1HUFS7XXWyy1KHahbzb5taDzZOJuPWaH4iP/sf89Lkr+f5/Y
ls+i7QVAq60+2GBZd5VU92P/PzlhMU3oG2Km/e8/YMCQ5Phqudg4yJr3lwgbsj4T
hOK5Uk2g8B+hNPcPuzgQkJhYQs/h85QuLk0FiyF5eq2MtQ35AsRH/gsswKtEDed+
NnXhazamJU4+TGgFkhOB5/WYR+48qE8/XsPrdO3mf20fslg8UHrnfEmppfr6a452
nkaPoblkOpl2UNBjP076S8/Ua/J6XXIti+r8+pc25j6fSKQFQ/TyYpZbF2gGZpxA
IFNqVo5kbBe0lFNhJLMwhPcxXevN3nNX+UvEphQUXQaRmbFQ7EVgs/RrYdYEpFZX
fOS9GVPHGI6mpLU+i9n013QlCAtu60NMWKq+mh+t3dk4D0dHqK0hnYu0bFsF4EZU
iNv/X3H6rugULRBrt7sxvRU/uWKGUurhJ7AJvOA9SA0j9YsS3oe3RTut11Ry7liL
zdefGQWK0AaztAniGq8EOC7coAazLdIBNUtiwywf7yihaiL55IYtxMslS8T0bQRd
jWt85z35clxoMRdYyKyL
=U2aV
-----END PGP SIGNATURE-----

--qw1jpiGhEv1c2/gd--