From: jqb AT netcom DOT com (Jim Balter)
Subject: Re: Ctrl-C crashes bash
10 Mar 1997 13:07:23 -0800
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <332412F1.648F.cygnus.gnu-win32@netcom.com>
References: <199703100812 DOT JAA25428 AT sp057 DOT cern DOT ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Original-To: Valery Fine <Valeri DOT Faine AT cern DOT ch>
Original-CC: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Valery Fine wrote:
> 
> On  9 Mar 97 at 12:49, Sergey Okhapkin wrote:
> 
> > Samuel Tardieu wrote:
> > >
> > > Bob> a. Does anybody else have the problem that using control-C to
> > > Bob> terminate a running program crashes bash?
> > >
> > > This problem occured for me under Win95 but doesn't seem to show
> > > up under WinNT.
> > >
> >
> > On Windows NT 4.0 too...
> >
> 
>   It was posted several times to this list but so far no reply seen.
> 
>   The problem is (according Microsoft):
> 
> " ....
> Note  SIGINT is not supported for any Win32 application including
> Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32
> operating systems generate a new thread to specifically handle that
> interrupt. This can cause a single-thread application such as UNIX, to
> become multithreaded, resulting in unexpected behavior.
>                       ================================ !!!!
>   .... "

cygwin goes to some effort to change the original thread to run your
SIGINT handler (that you have set via signal()) rather than naively
running it from the SetConsoleCtrlHandler HandlerRoutine (namely,
exceptions.cc:ctrl_c_handler), so it wouldn't seem to be subject
to this multithreading problem.  I don't know what's causing the
bash problem, though it is quite possible that bash isn't expecting
a crtl-C because it is reading from the terminal in raw mode.

I do note that programs that *haven't* set a SIGINT handler often crash
upon ctrl-C.  The most obvious problem is

  if ((void *)u->self->sigs[sig].sa_handler == (void *)SIG_DFL)
    {
      /* We encode the signal stuff in the high 8 bits.
	 (sorta like the reverse of a standard wait)
	 This is so that ordinary dos progs can look at our
	 exit value. */
      /* FIXME: exit calls atexit handlers.  */
      exit ((sig<<8) | 0x10000);
    }

That exit call is utterly wrong, and apparently someone at cygwin knew
it.  It will flush stdio streams, which could crash if the process is in
the middle of a stdio call, which it usually is when you hit ctrl-c.
Simply changing it to _exit, as it should be, would probably go a long
ways, but still wouldn't quite be enough because the code that _exit
calls is not thread-safe; the process could be in the middle closing a
file or even in _exit (but that's a lot less likely than being in
stdio).  Of course, the whole of cygwin needs to be made thread-safe if
anyone is going to be able to use it with multi-threaded apps.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".