This is the mail archive of the
mailing list for the Cygwin project.
Problem with exception handling on alt stacks
- From: Erik Bray <erik dot m dot bray at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 31 May 2018 15:21:55 +0200
- Subject: Problem with exception handling on alt stacks
I recently ran into a tricky problem when working with cysignals 
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  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 
> 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  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...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple