Re: bash/cmd CTRL-C problem...

["Gregory W. Bond" <bond@research.att.com>]

Michael,

I agree that this behavior should be considered a bug since the bash cygwin
behavior differs from bash behavior on other unix platforms. This has caused
headaches for our project too.

Greg.

For the record, here is a very simple java test program that I sent to Troy when
we discussed this problem last November. This program simply intercepts CTL-C
and runs a shutdown hook prior to shutting down the Java VM. It works fine under
cmd.exe and cygwin ash, but does not work under cygwin bash.

public static void main(String[] argv) {

  Runtime.getRuntime().addShutdownHook(new Thread(new Shutdown(), "Shutdown"));
  Object waitingPlace = new Object();
  synchronized(waitingPlace) {
   try {
    waitingPlace.wait();
   } catch (InterruptedException e) {}
  }
 }
 private static class Shutdown implements Runnable {

  public void run() {
   System.out.println("ProcessManager - shutting down...");
  }
 }
}


Michael Rumpf wrote:

> Hi Gregory,
>
> thanks for the info.
>
> > This may be related to a problem that prevents the cygwin bash shell
> > from propagating ^C to Win32 child processes. This is a bug/feature of
> > the cygwin bash shell. See the threads at
> > http://cygwin.com/ml/cygwin/2001-11/msg01579.html and
> > http://www.cygwin.com/ml/cygwin/2001-08/msg01111.html for discussions of
> > this problem. I've also included some message excerpts that didn't make
> > it onto the cywin mailing list that provide some insight into the
> > rationale for the bug/feature.
>
> There seem to be two problems/features:
> 1. CTRL-C is not propagated to child processes.
> 2. Execution of the application is not continued after the CTRL-C signal is
> handled.
>
> Both problems seem to happen only when applications are linked against the
> MS crt libs and run under the bash.
> However, I can't believe that my problem (2nd) is seen as a feature. The
> bash behaves differently under Win32 and under any UNIX environment I'm
> using here (AIX, HPUX, Solaris, Linux). There I can just press CTRL-C and
> the main/parent process receives a SIGINT, sets a flag in the signal
> handler, continues execution at the point where it was interrupted and thus
> causes the main process to send CTRL-BREAK events to its children. For this
> to happen the application code must continue its execution rather than
> stopping after handling the signal. The correct behaviour can also be seen
> in cmd.exe and I believe in bash when your app is linked against the cygwin
> libs (I did not try this yet because it is no option for our application
> server launcher program). So the only case where the behaviour is different
> is when you have an app linked against the MS crt libs which is running
> under the bash. I wouldn't see this as a feature I would see this as a
> bug....
>
> Michael
>
> > Greg.
> >
> > Charlie wrote:
> >
> > > Hi,
> > >
> > > I submitted some additional posts, along with some stuff from another
> guy
> > > that had a pretty good clue what was going on. search for my email
> address
> > > as I haven't posted that much to the list so you shouldn't have to pick
> > > through too much. I'd send you a copy but its not handy at the moment.
> Let
> > > me know if you can't find it and I'll see if I can't dig some of them
> up.
> > >
> > > The bottom line is that cygwin/bash executes win32 executables by
> spawning
> > > off another bash shell and running the win32 app inside it. Any signals
> > > generated are received by the bash shell and not the win32 app. If your
> > > running Win2k run the task manager, compare to the "ps" command in
> cygwin,
> > > look at the process IDs, and you'll see this. So the control C kills the
> > > bash shell and the win32 app at the same time, hence any
> cleanup/destructors
> > > never get to finish, assuming they even got to start.
> > >
> > > According to the guy I was exchanging info with, who knew a lot more
> about
> > > the internals of cygwin, this is a feature that actually lets cygwin run
> DOS
> > > applications, and is not something to be "fixed". Given my lack of
> knowledge
> > > of the internals, I can argue with that :-)
> > >
> > > VR, Charlie
> > >
> >
> >
> >
> > Troy Noble wrote:
> >
> > > And just to be clear, you did set CYGWIN=tty before starting bash per
> the
> > > FAQ?
> > > I just have to double check to be sure.  If you already know this, just
> > > ignore.
> > > The best way to ensure this is to start a cmd.exe, type set CYGWIN=tty
> or
> > > set CYGWIN= as desired, and then \cygwin\bin\bash.exe.  Or you can set
> > > CYGWIN
> > > in your NT environment, logout, and login.  Or edit your cygwin.bat file
> to
> > > do
> > > it before it invokes "bash --login -i".  Any of those options work
> equally
> > > well.
> > > The key is that you do not want to set it in your .bashrc because by
> then it
> > > is
> > > too late because the process initialization has already been done.  The
> FAQ
> > > talks
> > > about this some more.
> > >
> >
> > Michael wrote:
> >
> > > Hi Corinna,
> > >
> > > thanks for the answer. No I haven't tried such an option as I must admit
> > > that I don't know about it.
> > > I will search for it in the docs and try to play around with it...
> > >
> > > Michael
> > >
> > >
> > > On Fri, 2001-12-21 at 16:24, Corinna Vinschen wrote:
> > > > On Fri, Dec 21, 2001 at 11:09:05AM +0100, Michael Rumpf wrote:
> > > > > Am I the only one having problems with this, or is this simply the
> wrong
> > > > > list to ask a question about the Cygwin bash... ??
> > > >
> > > > Nah, this is the right list.  Nobody has an answer, though.
> > > >
> > > > Did you try `CYGWIN=... tty ...' setting?
> > > >
> > > > Corinna
> > > >
> > > > >
> > > > > Michael
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Michael Rumpf"
> > > > > To:
> > > > > Sent: Thursday, December 20, 2001 10:11 AM
> > > > > Subject: Re: bash/cmd CTRL-C problem...
> > > > >
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > sorry for following up myself, but I found out that Cygwin equally
> handles
> > > > > > CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> > > > > > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last
> sentence).
> > > > > > This seems to be the source of the problem.
> > > > > > CTRL-BREAK under the cmd shell terminates the process after
> handling the
> > > > > > signal without further executing any code. The bad thing is that
> under
> > > > > bash
> > > > > > the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C
> !!
> > > > > >
> > > > > > If this is a design issue, can someone please explain what the
> reasons
> > > > > > are...
> > > > > >
> > > > > > We have an application that forks other processes. The main thread
> is
> > > > > > waiting for the signal handler to return in order to cleanly stop
> the
> > > > > child
> > > > > > processes. By just stopping the parent process the child processes
> keep
> > > > > > running and I have to kill them manually each time I press CTRL-C.
> The
> > > > > same
> > > > > > application is working fine under windows cmd shell and bash under
> Linux ,
> > > > > > HP-UX 10/11, AIX4.x, and SunOS 2.5+...
> > > > > >
> > > > > > Please help, I don't want to use the stupid windows cmd shell....
> ;-)
> > > > > >
> > > > > > Michael
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Michael Rumpf"
> > > > > > To:
> > > > > > Sent: Thursday, December 20, 2001 7:47 AM
> > > > > > Subject: bash/cmd CTRL-C problem...
> > > > > >
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm new to the list and I don't know if this problem is already
> solved,
> > > > > > but
> > > > > > > I couldn't find a hint neither on the archives nor on the FAQ or
> > > > > somewhere
> > > > > > > else on the net.
> > > > > > >
> > > > > > > My problem is related to bash/cmd and signal handling.
> > > > > > > In my app I installed a signal handler for SIGINT. The app is
> going into
> > > > > a
> > > > > > > wait loop and waiting for the exit flag from the signal handler
> to be
> > > > > set.
> > > > > > >
> > > > > > > When pressing CTRL-C in the windows cmd shell the application
> continues
> > > > > > > normally after the signal handler has been caught. Under bash
> the signal
> > > > > > > handler is also correctly called, but after that the app is
> exiting
> > > > > > > immediatly, i.e. not continuing with the code.
> > > > > > > Here is the source:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> ////////////////////////////////////////////////////////////////////////////
> > > > > > > /////////////////
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > >
> > > > > > > bool loop = true;
> > > > > > >
> > > > > > > extern "C" void signalHandler(int sig)
> > > > > > > {
> > > > > > >    switch( sig )
> > > > > > >    {
> > > > > > >       case SIGINT:  // == 2
> > > > > > >          printf("SIGINT=%d\n",sig);
> > > > > > >          break;
> > > > > > >       default:
> > > > > > >          printf("default=%d\n",sig);
> > > > > > >          break;
> > > > > > >    };
> > > > > > >    loop=false;
> > > > > > > }
> > > > > > >
> > > > > > > int main(int argc, char* argv[])
> > > > > > > {
> > > > > > >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> > > > > > >       return -1;
> > > > > > >    printf("### ctrlbreak: Waiting now...\n");
> > > > > > >    while(loop)
> > > > > > >      Sleep ((DWORD) 1000) ;
> > > > > > >    printf("### ctrlbreak: Finished waiting now...\n");
> > > > > > >    return 0;
> > > > > > > }
> > > > > > >
> > > > > >
> > > > >
> ////////////////////////////////////////////////////////////////////////////
> > > > > > > /////////////////
> > > > > > >
> > > > > > > Here the the output of the app under Win2K/bash:
> > > > > > > // bash                2.05a-2
> > > > > > > $ ./ctrlbreak.exe
> > > > > > > ### ctrlbreak: Waiting now...
> > > > > > > SIGINT=2
> > > > > > >
> > > > > > >
> > > > > > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > > > > > > bash-2.02$ ./ctrlbreak
> > > > > > > ### ctrlbreak: Waiting now...
> > > > > > > SIGINT=2
> > > > > > >
> > > > > > > // cmd.exe Win2k SP2
> > > > > > > ### ctrlbreak: Waiting now...
> > > > > > > SIGINT=2
> > > > > > > ### ctrlbreak: Finished waiting now...
> > > > > > >
> > > > > > >
> > > > > > > You can see that under the cmd shell the text "Finished waiting
> now..."
> > > > > is
> > > > > > > printed which does not come out under the bash. The app is not
> linked
> > > > > > > against any cygwin library. It is a plain VC++ console
> application. But
> > > > > > when
> > > > > > > I compile with gcc from the cygwin package I have the same
> result.
> > > > > > > Any hint would be greatly appreciated...
> > > > > > >
> > > > > > > Michael
> > > > > > >
> > > > > > > PS: I just downloaded the latest stable version 1.3.6 today...
> > >

--
Gregory W. Bond
AT&T Labs - Research
180 Park Avenue, Rm. D273, Bldg. 103
P.O. Box 971, Florham Park, NJ, 07932-0971, USA
tel: (973) 360 7216 fax: (973) 360 8187



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/