This is the mail archive of the cygwin@cygwin.com 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]

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


Hi Corinna,

I further investigated the bash CTRL-C problem and found out that pressing
CTRL-C in the bash is "nearly" the same as CTRL-BREAK. I tried all the
CYGWIN=tty/notty/<empty> combinations but that did not change anything...

Test application:
I have several sample applications, one in Java (myclass.java) and one in
C/C++ (myclass.cpp) which are forked via the Win32API call CreateProcess()
from the main application (signals.cpp). The main application installs
signal handlers for SIGINT and SIGBREAK. In the SIGINT case the code in the
main thread should be further executed when the signal handler finishes. In
the SIGBREAK case the process should just stop and also stop all the forked
children. The continuation of the process in the SIGINT case is crucial
because the handler sets a flag which causes the main thread to leave a loop
and send the child processes a CTRL-BREAK event. The CTRL-BREAK event is
important because the process has been created with the flag
CREATE_PROCESS_GROUP and only CTRL_BREAK can be used to terminate the
process (see
http://msdn.microsoft.com/library/en-us/dllproc/prothred_9dpv.asp:
CreateProcess disables the CTRL-C signal handler for processes created as a
process group). The problem is that the bash does not continue executing the
main thread of the process after the handling of SIGINT, the process
terminates without being able to send the termination message
(GenerateConsoleCtrlEvent) to the child processes. The main process stops
but the child process continue to live (You can see that the child process
is still running as it writes dots "." to the console). When pressing
CTRL-BREAK the behaviour is as it should be, the main thread is not further
executed and the main process and all the child processes are stopped.

The cmd shell works as it should be. CTRL-BREAK stops everything immediatly
and CTRL-C continues with the main thread after the signal was handled.

I guess it is worth mentioning that I don't use any of the Cygwin libc
stuff. The apps are linked against MS runtime libs. The application is just
started from the bash (I can't switch to another runtime lib as our project
is huge and only the MS runtime is officially supported). I use the bash for
convenience reasons as we support several UNIX platforms where the bash is
our standard shell. Only under Win2K we "officially" use the cmd shell
because of the broken signal handling...

You can reproduce the problem with the sample applications attached. You
need to tweak the paths in the Makefile and the path to the Java VM in the
file signals.cpp. I also attached an output of "cygcheck -s -v -h" to the
mail.

Michael

----- Original Message -----
From: "Michael Rumpf" <michael@rumpfonline.de>
To: <cygwin@cygwin.com>
Sent: Friday, December 21, 2001 11:09 AM
Subject: Re: bash/cmd CTRL-C problem...


> Am I the only one having problems with this, or is this simply the wrong
> list to ask a question about the Cygwin bash... ??
>
> Michael
>
> ----- Original Message -----
> From: "Michael Rumpf" <michael@rumpfonline.de>
> To: <cygwin@cygwin.com>
> 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" <michael@rumpfonline.de>
> > To: <cygwin@cygwin.com>
> > 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 <windows.h>
> > > #include <stdio.h>
> > > #include <signal.h>
> > >
> > > 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...
> > >
> > >
> > >
> > > --
> > > 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/
> > >
> > >
> >
> >
> > --
> > 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/
> >
>
>
> --
> 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/
>
>

Attachment: Cygcheck.zip
Description: Zip compressed data

Attachment: Signals.zip
Description: Zip compressed data

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

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