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=UVE0LwcCe80SULhOtvBXd9pzaJJQIpIZFK/+6Zkh/XPRcB3hxEmVY
	gx1rWMeUeT5ZLvbe1oMw2Dp9g+w4ejIhwlW5ghXB1V++91esbah8KK2CmKcUBzAI
	V/m4e+qf+3gaS3wOpvfZlwZ+8aPSa1iuy3gHgLhmfEPjBiHj44YDoI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 1 Jun 2018 12:08:35 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem with exception handling on alt stacks
Message-ID: <20180601100835.GB6322@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAOTD34aOWu6MXD3ekCjo5dXpK00wkxB_9uNnZn0x0n4AiCwNLg AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd"
Content-Disposition: inline
In-Reply-To: <CAOTD34aOWu6MXD3ekCjo5dXpK00wkxB_9uNnZn0x0n4AiCwNLg@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)

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

On May 31 15:21, Erik Bray wrote:
> Hi all,
>=20
> I recently ran into a tricky problem when working with cysignals [1]
> on Cygwin:  Cysignals provides signal handlers for code written in C
> or Cython running in a Python interpreter, which converts otherwise
> unhandled signals into Python exceptions.
>=20
> It recently started using sigaltstack [2] to provide an alternate
> stack to run signal handlers on, specifically for SIGSEGV (in case the
> cause thereof was a stack overflow).
>=20
> Cygwin supports this in principle, but things get pretty flaky at that
> point, because if any exception occurs while running on an altstack,
> Cygwin will handle it if the exception came from Cygwin itself, but
> not otherwise, per this note [3]
>=20
> > TODO: What we do here is to handle only __try/__except blocks in Cygwin.
> > "Normal" exceptions will simply exit the process. Still, better
> > than nothing... */
>=20
> Is that really better than nothing though?  The result is that the
> process dies with a (Cygwin) exit code of 0.  This is quite
> surprising!  Even if there were really nothing else to be done I
> wonder if Cygwin could try as hard as possible to at least set a
> non-zero exit code in this case.
>=20
> Now, it's true what comment above that says:
>=20
> > normal SEH handlers are skipped, because the OS exception
> > handling considers the current (alternate) stack "broken"
>=20
> However, I was able to work around this in cysignals [4] by adding a
> VectoredContinueHandler which, in this case, is at least able to
> convert the exception code to the appropriate POSIX return code and
> exit the process.  And superficially it seems to work quite reliably.
> But I wonder if there isn't something "wrong" about this from the
> Cygwin perspective, and if it shouldn't at least try to do the same...

Good point.  I'm not sure I have time to look into this for the time
being, but I'm not at all opposed to patches in this area.


Corinna

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

--WYTEVAkct0FjGQmd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlsRGyIACgkQ9TYGna5E
T6BkBA/7BVFMVjAuj/TsUAiElhYPJUAqRs0M+VuLbqIWFEw1OmV3xFg7rcMoXsqh
7uoAYVsFStHyRWDqVqXhix9pP8a9DEO7I/jsN+tX/YY3Pr96QBry35nJ16hUsTTY
D29S2ociYx4v1FAWpLujbMWxE5GOXCaFSi6FEHO7AU1ugNe4JC/9st3i+rmQu2gP
fSPxRFk5gXDaCSoKgZGnDWKZLB/GhV7POvPhMBN1xC/e+kI2H7dtlR0XrUDQ0NpT
bde8xCzgn2CpJ0CFdjOZsZUtVorX7PSjhWr9VbbXK6Dr/r1zALdutIfrK9lj291B
eMZyFdlKJWWCzzYFuJn9+I7me66n8d9adzvICDVb9bsGImJ5x81zqaelIOc+x7wp
ITTuC6iVk7a7eShhhqE5rnQt35luWuteGLoA0bUZ3Ol2Z0XatG1oVax5RBUw1SoN
jGma4UruroXe6nFUp0fFe7Qpw+ZzntWAY29y38kAgZrriC2wJ5KHS8cJOdsJki8Z
OStzMivCQDISuyTGExrrWua8/HXQ14s7Kisx8He8dpXM9XXBlPhaFbYgfgKhmIwz
fJXFbkM3soNtFdh6njGjb+JBs9gAIo6ZLrFoBpAmDOz84IJtYxpQTD1xkMYdNS2J
DE/GqBHKTVTk4CNWzIaQVoCgDRe6XQzC0LrciLsMbZE8aopXzLc=
=yubp
-----END PGP SIGNATURE-----

--WYTEVAkct0FjGQmd--