This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

abort() bug


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:

$ cat foo.c
#include <signal.h>
#include <stdio.h>
#include <assert.h>
#include <stdlib.h>

void abort_handler (int i)
{
  puts ("goodbye, cruel world");
  exit (1);
}

int main (int argc, char **argv)
{
  if (argc == 1)
    signal (SIGABRT, abort_handler);
  assert (0);
  abort ();
}
$ gcc -o foo foo.c
$ ./foo; echo $?
assertion "0" failed: file "foo.c", line 15, function: main
1
$ ./foo 1; echo $?
assertion "0" failed: file "foo.c", line 15, function: main
Aborted (core dumped)
134
$ gcc -o foo -Wall foo.c -DNDEBUG
$ ./foo; echo $?
1
$ gcc -mno-cygwin -o foo -Wall foo.c -DNDEBUG
$ ./foo; echo $?

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
goodbye, cruel world
1
$ ./foo 1; echo $?

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.

-- 
Eric Blake




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]