Mail Archives: cygwin/2008/06/06/13:55:11
On Fri, Jun 06, 2008 at 04:32:27PM +0000, Eric Blake wrote:
>Any reason that cygwin abort() closes all stdio streams prior to issuing
>SIGABRT? This is a difference from Linux, and makes it difficult to install a
>cleanup handler that prints a nicer error message. POSIX states that "The
>abnormal termination processing... may include an attempt to effect fclose() on
>all open streams", but is also clear that abnormal process is thwarted if "the
>signal SIGABRT is being caught and the signal handler does not return". STC:
>
>[snip]
>
>This application has requested the Runtime to terminate it in an unusual way.
>Please contact the application's support team for more information.
>3
>
>
>Obviously the SIGABRT handler is running whether abort is called directly or
>via a failed assertion, based on the change in exit status and lack of core
>dump. But it seems a shame that stdio has been lost. On Linux and mingw, this
>example correctly prints "goodbye, cruel world" when the handler is invoked
>(well, mingw abort() injects extra text regardless of whether there is an abort
>handler installed, and the lack of a handler exits with 3 rather than 134).
>
>In other words, I think that signal.cc needs to rearrange the
>_GLOBAL_REENT->__cleanup to occur _after_ _my_tls.call_signal_handler.
I think you're right. The call to call_signal_handler was added years
after the addition of the cleanup so it would make sense to move the
cleanup handling after that.
Want to submit a patch?
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -