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:mime-version:from:date:message-id:subject:to
	:content-type; q=dns; s=default; b=DSrZpe8dS5tFME6B6qw6zISj2hh1T
	5z+TzyFtoEKKwH1NMsnVTo2nNc8vbVI7q8iHg+ZIA84BMfrh7kOMBvZl60I2+PLs
	Yt9L/YjavHq3obhpbAIpdUIAZqP57KyPs7TC35RMyEatT1X17shQ4IfTrBNW3W5i
	AMES5u8+DHBrX0=
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:mime-version:from:date:message-id:subject:to
	:content-type; s=default; bh=SSdZRlzb/HPlQg+D1ALcg/qcgTo=; b=kvG
	mPgUKLoEwHzxRuG7Qb2lZwGnxwb9hs67TOFQ8OuOd1ffiwTfjKg6aIGNupRnN4K5
	NNQe9DBL+sXVUONh3YTzJ/J+m6WP6wLjggO0oLLrSWpkqEsH9ic+KW5JaK2o8TGM
	USPPG4mT6QXVWPzC/8gkGp3S+gVNvnT4oSdheOD0=
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=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=principle, converts, alt
X-HELO:	mail-it0-f54.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HCX3lOwAVRnTSexSgiuFTQdNmhEKqzJcwx5KnNZQIQw=; b=RathXQ2iyJhCwf6ZLc2Wsae53WwymloszlpCit4fPTCIEUtk8Ojzvv6OlFSUwn3k7T IwZPaW6xbzCX6XBD6+J9YNgUXDUDxkj3b64fTc6TWtEa66HyljYoBp7Vu1mnQPhxof95 cS6R0c4mwux/uP9fC033euB3fi5GxFtTvPQ4kJ7Ad/ATXMwLNynz4T6JR6MejzDW/r34 1gXEFm2QwO/QbdYcSpqMgnQzcoGZQzoqFJ0CFZFlnNRJLb55KmK0A40etaLoriMwYBpi cT/KbhBsiToI3dZ9DLffK7xuT32THDPwDXvEwuBNmjoIGmvaVoSRgpxap7XXk0P6dTk6 JAEA==
X-Gm-Message-State:	APt69E15ISO72+Z4TzEeSztpNA434dsu+HKGHiCqWNovvxlNu05lDJzw 9XoNpC2hBdOgr7nnuTyp5ANL0Q5rccVQ9FJi/OzWeNty
X-Google-Smtp-Source:	ADUXVKJKYWmfwdHJEP/eDRRbAzR1ppXabMYwvxRLosD8oOjTcGU9DKILc3nLw/5TAUoOjEEjqPefzIj9ZQM96CQJiIg=
X-Received:	by 2002:a24:9486:: with SMTP id j128-v6mr995033ite.107.1527772916136; Thu, 31 May 2018 06:21:56 -0700 (PDT)
MIME-Version:	1.0
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Thu, 31 May 2018 15:21:55 +0200
Message-ID:	<CAOTD34aOWu6MXD3ekCjo5dXpK00wkxB_9uNnZn0x0n4AiCwNLg@mail.gmail.com>
Subject:	Problem with exception handling on alt stacks
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

Hi all,

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.

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

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]

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

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.

Now, it's true what comment above that says:

> normal SEH handlers are skipped, because the OS exception
> handling considers the current (alternate) stack "broken"

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

Best,
E


[1] https://github.com/sagemath/cysignals
[2] http://man7.org/linux/man-pages/man2/sigaltstack.2.html
[3] https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/exceptions.cc;h=77eff05707f95f7277974fadbccf0e74223d8d1c;hb=HEAD#l593
[4] https://github.com/sagemath/cysignals/pull/83/files#diff-4b8e0979558a11b7d1ad11467c91daac

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -