* bash/cmd CTRL-C problem... @ 2001-12-19 23:48 Michael Rumpf 2001-12-20 1:28 ` Michael Rumpf 0 siblings, 1 reply; 35+ messages in thread From: Michael Rumpf @ 2001-12-19 23:48 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2001-12-19 23:48 bash/cmd CTRL-C problem Michael Rumpf @ 2001-12-20 1:28 ` Michael Rumpf 2001-12-21 2:17 ` Michael Rumpf 0 siblings, 1 reply; 35+ messages in thread From: Michael Rumpf @ 2001-12-20 1:28 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2001-12-20 1:28 ` Michael Rumpf @ 2001-12-21 2:17 ` Michael Rumpf 2001-12-21 7:27 ` Corinna Vinschen 2002-01-04 3:51 ` Michael Rumpf 0 siblings, 2 replies; 35+ messages in thread From: Michael Rumpf @ 2001-12-21 2:17 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2001-12-21 2:17 ` Michael Rumpf @ 2001-12-21 7:27 ` Corinna Vinschen 2001-12-21 8:46 ` Michael Rumpf 2002-01-04 3:51 ` Michael Rumpf 1 sibling, 1 reply; 35+ messages in thread From: Corinna Vinschen @ 2001-12-21 7:27 UTC (permalink / raw) To: cygwin 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" <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/ -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin@cygwin.com Red Hat, Inc. -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2001-12-21 7:27 ` Corinna Vinschen @ 2001-12-21 8:46 ` Michael Rumpf 0 siblings, 0 replies; 35+ messages in thread From: Michael Rumpf @ 2001-12-21 8:46 UTC (permalink / raw) To: Corinna Vinschen 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" <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/ > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Developer mailto:cygwin@cygwin.com > Red Hat, Inc. > > -- > 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2001-12-21 2:17 ` Michael Rumpf 2001-12-21 7:27 ` Corinna Vinschen @ 2002-01-04 3:51 ` Michael Rumpf 2002-01-04 9:04 ` Christopher Faylor 1 sibling, 1 reply; 35+ messages in thread From: Michael Rumpf @ 2002-01-04 3:51 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 7963 bytes --] 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 #2: Cygcheck.zip --] [-- Type: application/x-zip-compressed, Size: 4013 bytes --] [-- Attachment #3: Signals.zip --] [-- Type: application/x-zip-compressed, Size: 3778 bytes --] [-- Attachment #4: Type: text/plain, Size: 214 bytes --] -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-04 3:51 ` Michael Rumpf @ 2002-01-04 9:04 ` Christopher Faylor 2002-01-07 0:46 ` Michael Rumpf 0 siblings, 1 reply; 35+ messages in thread From: Christopher Faylor @ 2002-01-04 9:04 UTC (permalink / raw) To: cygwin On Fri, Jan 04, 2002 at 12:52:43PM +0100, Michael Rumpf wrote: >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... > >[snip] > >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. Here's the harsh reality: it is extremely unlikely that anyone is going to investigate this. If you are using non-cygwin apps with bash and CTRL-C doesn't work then you are on your own. I will enthusiastically inspect and evaluate any fixes that you provide to cygwin to rectify this situation. The fixes must not break current CTRL-C behavior with cygwin apps. You are one of a handful of people reporting similar problems. Everyone seems to be trying to do basically the same thing. They're building non-cygwin java apps and complaining that CTRL-C doesn't work right. However, since we are all *cygwin* developers it is not likely that we'll want to go to the effort of loading non-cygwin, java software on our system to track your problem down for you. I could be wrong. Maybe someone is actively working on this. If so, I hope that person steps forward and offers some insight into how they are progressing and what their proposed fix might be. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-04 9:04 ` Christopher Faylor @ 2002-01-07 0:46 ` Michael Rumpf 2002-01-07 1:10 ` Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Michael Rumpf @ 2002-01-07 0:46 UTC (permalink / raw) To: cygwin Hi Christopher, > Here's the harsh reality: it is extremely unlikely that anyone is going > to investigate this. If you are using non-cygwin apps with bash and > CTRL-C doesn't work then you are on your own. OK. > I will enthusiastically inspect and evaluate any fixes that you provide > to cygwin to rectify this situation. The fixes must not break current > CTRL-C behavior with cygwin apps. > > You are one of a handful of people reporting similar problems. Everyone > seems to be trying to do basically the same thing. They're building > non-cygwin java apps and complaining that CTRL-C doesn't work right. It is not a Java app. It is a plain C/C++ app which forks either a C/C++ or a Java app. You don't have to compile the included Java app, you can just use the two C/C++ apps to reproduce the problem. The problem is that the signal handling of the bash is not working correctly in the C/C++ app which forks others. The CTRL-C (SIGINT) terminates the app after executing the signal handler in the same way CTRL-BREAK (SIGBREAK) does but in opposite to the CTRL-BREAK the child processes are not taken down. The forking app goes into a loop and waits for a flag to be raised when the SIGINT occurs. But under bash this never happens. The app is always terminated after handling the signal. After the loop the app tries to send CTRL-BREAK signals to the child apps and because it is terminated immediately the code is never reached. > However, since we are all *cygwin* developers it is not likely that > we'll want to go to the effort of loading non-cygwin, java software on > our system to track your problem down for you. The problem is in a C/C++ app which is linked against Microsoft runtime libs and the signal handling goes wrong there. First I suspected that it has something to do with Java but, and that is what the test case shows, it is independent of it. I'm "just" use the Cygwin shell environment to have the same shell under NT as under UNIX. I had a look at how the signal handling in the bash works, but I found it very complicated and I don't have the time to track it down. If nobody is interested making non-cygwin apps work the right way under the bash than I have to use another approach by starting a windows cmd shell to launch the C/C++ app to make the signal handling work... The assumption that > I could be wrong. Maybe > someone is actively working on this. If so, I hope that person steps > forward and offers some insight into how they are progressing and what > their proposed fix might be. That would of course be great... Thanks, Michael -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-07 0:46 ` Michael Rumpf @ 2002-01-07 1:10 ` Robert Collins 2002-01-07 1:58 ` Michael Rumpf 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-07 1:10 UTC (permalink / raw) To: Michael Rumpf; +Cc: cygwin On Mon, 2002-01-07 at 19:47, Michael Rumpf wrote: > The problem is that the signal handling of the bash is not working correctly > in the C/C++ app which forks others. I'm not clear: Is the app that forks others a Cygwin app, or not? ie: as a process chain is it bash (cygwin) app1 (cygwin) app2 (MS CRT) or is it bash (cygwin) app1 (MS CRT) app2 (MS CRT) ? > The CTRL-C (SIGINT) terminates the app > after executing the signal handler in the same way CTRL-BREAK (SIGBREAK) > does but in opposite to the CTRL-BREAK the child processes are not taken > down. The forking app goes into a loop and waits for a flag to be raised > when the SIGINT occurs. But under bash this never happens. By this are you implying that this: cmd.exe app1 (cygwin/MS CRT (see above)) app2 (MS CRT) behaves as you expect? > > However, since we are all *cygwin* developers it is not likely that > > we'll want to go to the effort of loading non-cygwin, java software on > > our system to track your problem down for you. > > I'm "just" use the Cygwin shell environment to have the same shell under NT > as under UNIX. > had a look at how the signal handling in the bash works, > but I found it very complicated and I don't have the time to track it down. > If nobody is interested making non-cygwin apps work the right way under the > bash than I have to use another approach by starting a windows cmd shell to > launch the C/C++ app to make the signal handling work... It's not a matter of interest. Developer time spent fixing bugs is much more effective that developer time spent isolating bugs. If you can provide clear documentation on whats occuring, then maybe we can fix it. I for one am not going to contribute 8-16 hours trying to isolate a bug that doesn't affect me, and that I've no motivation (per se) to solve. > > I could be wrong. Maybe > > someone is actively working on this. If so, I hope that person steps > > forward and offers some insight into how they are progressing and what > > their proposed fix might be. > > That would of course be great... Unfortunately, AFAIK Chris is correct. He's got a pretty good feel what the 'core' developers are working on :}. This doesn't affect me, but I'm willing to put a coupla hours in on it - starting with a clear repeatable test case - which you are part way to providing. Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-07 1:10 ` Robert Collins @ 2002-01-07 1:58 ` Michael Rumpf 2002-01-07 2:30 ` Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Michael Rumpf @ 2002-01-07 1:58 UTC (permalink / raw) To: cygwin; +Cc: Robert Collins Hi Robert, > On Mon, 2002-01-07 at 19:47, Michael Rumpf wrote: > > > > The problem is that the signal handling of the bash is not working correctly > > in the C/C++ app which forks others. > > I'm not clear: Is the app that forks others a Cygwin app, or not? > > ie: as a process chain is it > bash (cygwin) > app1 (cygwin) > app2 (MS CRT) > > or is it > bash (cygwin) > app1 (MS CRT) > app2 (MS CRT) Ok, I assume that the comment "cygwin" means that the app is linked against cygwin runtime libs. If I got that right it is the second case: bash (cygwin, of course) app1 = "signals (MS CRT)" app2 = "myclass.exe (MS CRT)" or "java myclass (???)" > > The CTRL-C (SIGINT) terminates the app > > after executing the signal handler in the same way CTRL-BREAK (SIGBREAK) > > does but in opposite to the CTRL-BREAK the child processes are not taken > > down. The forking app goes into a loop and waits for a flag to be raised > > when the SIGINT occurs. But under bash this never happens. > > By this are you implying that this: > cmd.exe > app1 (cygwin/MS CRT (see above)) > app2 (MS CRT) > behaves as you expect? cmd.exe bash (cygwin, of course) app1="signals (MS CRT)" app1 app2="myclass.exe (MS CRT)" or "java myclass (???)" yes here the behaviour is correct !! When pressing CTRL-C the execution continues after handling the signal. The child apps are taken down by sending a CTRL-BREAK event. *snip* > > It's not a matter of interest. Developer time spent fixing bugs is much > more effective that developer time spent isolating bugs. If you can > provide clear documentation on whats occuring, then maybe we can fix it. > > I for one am not going to contribute 8-16 hours trying to isolate a bug > that doesn't affect me, and that I've no motivation (per se) to solve. I know this, sorry if phrasing to harsh. I'm not a native speaker so please don't get me wrong, I simply don't have the time to get familiar with the complex Cygwin internals. I would never be able to tell whether a patch will not break other cygwin apps so it will always be some kind of quick hack... > > > I could be wrong. Maybe > > > someone is actively working on this. If so, I hope that person steps > > > forward and offers some insight into how they are progressing and what > > > their proposed fix might be. > > > > That would of course be great... > > Unfortunately, AFAIK Chris is correct. He's got a pretty good feel what > the 'core' developers are working on :}. > > This doesn't affect me, but I'm willing to put a coupla hours in on it - > starting with a clear repeatable test case - which you are part way to > providing. Great, the attachment of one of my previous mails should give you a repeatable test case at hand. It includes the signals.cpp (app1), myclass.cpp/myclass.java (app2) and a Makefile to compile it (the makefile needs some updates to the paths used there). You don't have to compile the Java class just compile the C/C++ apps and launch "signals cpp" which results in forking the C/C++ child app myclass.exe. Thanks a lot for investigating the issue. I will provide you any help you need. We are around 200 developers here building a fairly huge application server and most of the developers have to stick with the windows cmd shell as it is inconvenient under Windows to start the Task Manager each time when shutting down the application server in order to kill around 7 processes manually. We are currently using a very old version (B20.1) for our internal *build process* and we are evaluating currently to move to a current version. It would be great if the issue could be fixed so that we could use an updated version of the bash to make the only but most annoying problem go away... I have used the latest stable version of Cygwin and the bash to reproduce the problem. The old version mentioned above is only used in the build process of our application server... Michael -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-07 1:58 ` Michael Rumpf @ 2002-01-07 2:30 ` Robert Collins 2002-01-07 2:56 ` Michael Rumpf 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-07 2:30 UTC (permalink / raw) To: Michael Rumpf, cygwin ----- Original Message ----- From: "Michael Rumpf" <michael@rumpfonline.de> Yes, that is what I meant. > bash (cygwin, of course) > app1 = "signals (MS CRT)" > app2 = "myclass.exe (MS CRT)" or "java myclass (???)" Lets leave java to the side. If we solve it with MS CRT, and java apps still have problems, then that becomes a new bug. Why? because there are multiple JVM's to consider, making it harder to setup a test environment. And because I suspect that a solution to one will solve the other. > > By this are you implying that this: > > cmd.exe > > app1 (cygwin/MS CRT (see above)) > > app2 (MS CRT) > > behaves as you expect? > > cmd.exe > bash (cygwin, of course) > app1="signals (MS CRT)" app1 > app2="myclass.exe (MS CRT)" or "java myclass (???)" > > yes here the behaviour is correct !! When pressing CTRL-C the execution > continues after handling the signal. The child apps are taken down by > sending a CTRL-BREAK event. Ok. let me confirm I understand everything. * Failure case * 1) double click on a shortcut to cygwin.bat from a default install of cygwin 2) run ./signals.exe 3) ./myclass.exe is automatically executed (BTW: this is not fork() - fork() requires a cygwin linked signals.exe. In unix terms, this is a spawned program. 4) Hit CTRL-C. 5) The user is returned to the bash shell started via 1), but myclass.exe is left running. * success case * 1) double click on a shortcut to cmd.exe 2) run X:\cygwin\cygwin.bat 3) run ./signals.exe 4) ./myclass.exe is automatically executed (BTW: this is not fork() - fork() requires a cygwin linked signals.exe. In unix terms, this is a spawned program. 5) Hit CTRL-C. 6) The user is returned to the bash shell started via 2), and myclass.exe is terminated correctly. Please edit the above as needed to correctly show the actions taken and the expected outcome, to prevent me erroneously reporting no-fault-found or no-success-found etc. > Great, the attachment of one of my previous mails should give you a > repeatable test case at hand. It includes the signals.cpp (app1), > myclass.cpp/myclass.java (app2) and a Makefile to compile it (the makefile > needs some updates to the paths used there). You don't have to compile the > Java class just compile the C/C++ apps and launch "signals cpp" which > results in forking the C/C++ child app myclass.exe. I've not archived those mails. Can you please send me (as an off-list email, separate to your on-list response) the relevant files. I presume they will build with gcc -mno-cygwin ? (If Visual C++ is required to build them, please provide a .exe). Cheers, Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-07 2:30 ` Robert Collins @ 2002-01-07 2:56 ` Michael Rumpf 2002-01-07 5:15 ` CGF: please review my logic " Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Michael Rumpf @ 2002-01-07 2:56 UTC (permalink / raw) To: cygwin > Yes, that is what I meant. > > > bash (cygwin, of course) > > app1 = "signals (MS CRT)" > > app2 = "myclass.exe (MS CRT)" or "java myclass (???)" > > Lets leave java to the side. If we solve it with MS CRT, and java apps > still have problems, then that becomes a new bug. Why? because there are > multiple JVM's to consider, making it harder to setup a test > environment. And because I suspect that a solution to one will solve the > other. OK, no problem. Java processes are created and they can be taken down by sending them CTRL-BREAK signals (You need to start the Sun VM with parameter -Xrs to make this work, otherwise you will just see a thread dump because the standard VM establishes a SIGBREAK handler which prints stack dumps of all running threads) > > > By this are you implying that this: > > > cmd.exe > > > app1 (cygwin/MS CRT (see above)) > > > app2 (MS CRT) > > > behaves as you expect? > > > > cmd.exe > > bash (cygwin, of course) > > app1="signals (MS CRT)" app1 > > app2="myclass.exe (MS CRT)" or "java myclass (???)" > > > > yes here the behaviour is correct !! When pressing CTRL-C the > execution > > continues after handling the signal. The child apps are taken down by > > sending a CTRL-BREAK event. > > Ok. let me confirm I understand everything. > > * Failure case * > 1) double click on a shortcut to cygwin.bat from a default install of > cygwin > 2) run ./signals.exe > 3) ./myclass.exe is automatically executed (BTW: this is not fork() - > fork() requires a cygwin linked signals.exe. In unix terms, this is a > spawned program. > 4) Hit CTRL-C. > 5) The user is returned to the bash shell started via 1), but > myclass.exe is left running. > > * success case * > 1) double click on a shortcut to cmd.exe > 2) run X:\cygwin\cygwin.bat No. I do not run cygwin.bat ! It is just pure cmd.exe !!! > 3) run ./signals.exe > 4) ./myclass.exe is automatically executed (BTW: this is not fork() - > fork() requires a cygwin linked signals.exe. In unix terms, this is a > spawned program. OK, myclass.exe is spawned program... > 5) Hit CTRL-C. > 6) The user is returned to the bash shell started via 2), and > myclass.exe is terminated correctly. The user is returned to the cmd.exe shell started via 1) and myclass.exe is terminated correctly. > Please edit the above as needed to correctly show the actions taken and > the expected outcome, to prevent me erroneously reporting no-fault-found > or no-success-found etc. > > > Great, the attachment of one of my previous mails should give you a > > repeatable test case at hand. It includes the signals.cpp (app1), > > myclass.cpp/myclass.java (app2) and a Makefile to compile it (the > makefile > > needs some updates to the paths used there). You don't have to compile > the > > Java class just compile the C/C++ apps and launch "signals cpp" which > > results in forking the C/C++ child app myclass.exe. > > I've not archived those mails. Can you please send me (as an off-list > email, separate to your on-list response) the relevant files. I presume > they will build with gcc -mno-cygwin ? (If Visual C++ is required to > build them, please provide a .exe). I have no Makefile for compiling the test case with gcc at hand. The general opinion here at my company is that the code generated by gcc is too slow. So we are using the native compilers under the different platforms. The decision to use the native compilers has been made a few years ago and I guess a lot has changed since then, but we have decided last year to move to Java and so adapting everything to gcc would be a one year effort which nobody wants to invest because we have finally decided to move to Java completely. This is also not a single step task and until that has not been achieved many of the building blocks, like the app server launcher, remains in C++ AIX -> xlC_r NT/IA64 -> cl.exe Linux -> GCC HPUX -> aCC Solaris -> CC Michael -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* CGF: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 2:56 ` Michael Rumpf @ 2002-01-07 5:15 ` Robert Collins 2002-01-07 6:18 ` Michael Rumpf 2002-01-07 8:50 ` CGF: " Christopher Faylor 0 siblings, 2 replies; 35+ messages in thread From: Robert Collins @ 2002-01-07 5:15 UTC (permalink / raw) To: Michael Rumpf, cygwin Ok. I didn't realise that signal() is implemented in the standard VC++ libraries. Can you tell me any details of the signal implementation you are using on win32? If you wished to follow clean room r/e for this, I can implement the signal sending side to match up with what your library expects. Also, according to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore9 8/HTML/_crt_signal.asp SIGINT is not supported for win32 programs. I quote: "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. " As for why you see the current behaviour, I'm a little mystified. Here's why: Firstly, here's a snippet of the output of a strace of kill -2 <signals.exe pid> 2149 2816627 [main] kill 920 _kill: kill (3656, 2) 1542 2818169 [main] kill 920 sig_send: pid 3656, signal 2, its_me 0 1387 2819556 [main] kill 920 getsem: pid 3656, ppid 3648, wait 1000, initializing 0 1776 2821332 [main] kill 920 sig_send: Not waiting for sigcomplete. its_me 0 signal 2 3817 2825149 [main] kill 920 sig_send: returning 0 from sending signal 2 2529 2827678 [main] kill 920 kill_worker: 0 = kill_worker (3656, 2) The getsem line is whats interesting: This is retrieving the semaphore used to syncronise the signalling across process's. It succeeds! (I'm running a slightly modified cygwin here, which as the patch at the end of this email shows (in combination with the source :}) should always indicate if there is an error). It shouldn't succeed - Sysinternals process explorer shows signals.exe as having no semaphores at all, let alone a named semaphore with the correct name. further investigation finds that bash has got the semaphore for the process pid that signals has, and that Ctrl-C is actually being recieved by bash, which is running as a sub-process. Doing a ps in another bash shell will show /path/to/signals against a PID that if you look up in the windows PID list is actually bash. Cygwin is pretending that signals.exe is a cygwin app via the use of a dummy bash process, that has called exec(), but is kept around to recieve signals etc... So here's my best guess as to whats happening: When you hit CTRL-C, it propogates to signals.exe (handled as you expect) bash.exe (still attached to the console and gets handled via default signal handler - exit and terminate all subprocess's - which kills signals.exe) If you have time, and wanted to test this, you could make a three level test program. I would appreciate if you could do this as it be an independent confirmation of the analysis. outer level - recieved CTRL-C, prints that it's got it, and quits(without terminateding signals.exe). middle level - signals.exe inner level - myclass.exe. I'd expect that you'd see the outer level get killed in the same fashion as you currently see signals.exe die. the middle level would run and kill myclass correctly. As for how to fix this, I won't speculate until we confirm this analysis. I've flagged this email for Chris's attention (I've not done much on the signal handling code) and if he agrees with my analysis I will look at ways to address this somewhat...inconvenient behaviour :} Rob ==================== Index: sigproc.cc =================================================================== RCS file: /cvs/src/src/winsup/cygwin/sigproc.cc,v retrieving revision 1.95.2.2 diff -u -p -r1.95.2.2 sigproc.cc --- sigproc.cc 2002/01/04 03:56:10 1.95.2.2 +++ sigproc.cc 2002/01/07 12:54:59 @@ -953,7 +953,6 @@ getsem (_pinfo *p, const char *str, int set_errno (ESRCH); else set_errno (EPERM); - return NULL; } } -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 5:15 ` CGF: please review my logic " Robert Collins @ 2002-01-07 6:18 ` Michael Rumpf 2002-01-07 8:50 ` CGF: " Christopher Faylor 1 sibling, 0 replies; 35+ messages in thread From: Michael Rumpf @ 2002-01-07 6:18 UTC (permalink / raw) To: cygwin > Ok. > I didn't realise that signal() is implemented in the standard VC++ > libraries. > Can you tell me any details of the signal implementation you are using > on win32? > If you wished to follow clean room r/e for this, I can implement the > signal sending side to match up with what your library expects. > > Also, according to > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore9 > 8/HTML/_crt_signal.asp > I tried this with the signal() function as well as with the SetConsoleCtrlHandler() function (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/co nchar_599u.asp). The only difference was that the integer identifying the signal was different but in both cases but the behaviour was the same. That is the reason why I view these two ways of implementing the signal handling equivalent (I returned TRUE from the HandlerRoutine to indicate that the signal was handled and that no default action, like for example process termination should happen, but that did not change anything) > SIGINT is not supported for win32 programs. I quote: > "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. " I don't know how signals are treated/implemented in UNIX and what is maybe wrong with the approach of starting a new thread, so I must admit that I'm sure on how to interpret the statement above... > As for why you see the current behaviour, I'm a little mystified. > > Here's why: > > Firstly, here's a snippet of the output of a strace of kill -2 > <signals.exe pid> > > 2149 2816627 [main] kill 920 _kill: kill (3656, 2) > 1542 2818169 [main] kill 920 sig_send: pid 3656, signal 2, its_me 0 > 1387 2819556 [main] kill 920 getsem: pid 3656, ppid 3648, wait 1000, > initializing 0 > 1776 2821332 [main] kill 920 sig_send: Not waiting for sigcomplete. > its_me 0 signal 2 > 3817 2825149 [main] kill 920 sig_send: returning 0 from sending signal > 2 > 2529 2827678 [main] kill 920 kill_worker: 0 = kill_worker (3656, 2) > > The getsem line is whats interesting: This is retrieving the semaphore > used to syncronise the signalling across process's. > > It succeeds! (I'm running a slightly modified cygwin here, which as the > patch at the end of this email shows (in combination with the source :}) > should always indicate if there is an error). The signal is correctly recieved by the app signal.exe, that is not the problem. The problem is that the code after the loop (Line 139) while(loop) Sleep(DWORD) 1000); printf("\n>>> signals: Finished waiting now...\n"); // !!!!!!!!!!!!!! no executed !!!!!!!!!!!! is not executed. Therefore I can't shutdown any child processes correctly. Under cmd.exe the printf line gets executed and I can see the output in the console window.... > It shouldn't succeed - Sysinternals process explorer shows signals.exe > as having no semaphores at all, let alone a named semaphore with the > correct name. > > further investigation finds that bash has got the semaphore for the > process pid that signals has, and that Ctrl-C is actually being recieved > by bash, which is running as a sub-process. > > Doing a ps in another bash shell will show /path/to/signals against a > PID that if you look up in the windows PID list is actually bash. Cygwin > is pretending that signals.exe is a cygwin app via the use of a dummy > bash process, that has called exec(), but is kept around to recieve > signals etc... > > So here's my best guess as to whats happening: > When you hit CTRL-C, it propogates to > signals.exe (handled as you expect) > bash.exe (still attached to the console and gets handled via default > signal handler - exit and terminate all subprocess's - which kills > signals.exe) > > If you have time, and wanted to test this, you could make a three level > test program. I would appreciate if you could do this as it be an > independent confirmation of the analysis. > outer level - recieved CTRL-C, prints that it's got it, and > quits(without terminateding signals.exe). > middle level - signals.exe > inner level - myclass.exe. > > I'd expect that you'd see the outer level get killed in the same fashion > as you currently see signals.exe die. the middle level would run and > kill myclass correctly. I'm not sure why signal.exe should run when outer.exe gets a CTRL-C event. This is just another level... Nevertheless, I created a program called outer.exe which spawns signals.exe which in turn spawns myclass.exe. When I press CTRL-C outer.exe is terminated without executing any other code in outer.exe. See the source of outer.cpp Line 106 the text ">>> outer: Finished waiting now. Termintaing..." should be printed to the console after pressing CTRL-C. But this does not happen... Michael PS: I send you the source and the binary seperately... -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: CGF: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 5:15 ` CGF: please review my logic " Robert Collins 2002-01-07 6:18 ` Michael Rumpf @ 2002-01-07 8:50 ` Christopher Faylor 2002-01-07 15:00 ` Robert Collins 1 sibling, 1 reply; 35+ messages in thread From: Christopher Faylor @ 2002-01-07 8:50 UTC (permalink / raw) To: cygwin On Tue, Jan 08, 2002 at 12:15:27AM +1100, Robert Collins wrote: >Ok. >I didn't realise that signal() is implemented in the standard VC++ >libraries. >Can you tell me any details of the signal implementation you are using >on win32? >If you wished to follow clean room r/e for this, I can implement the >signal sending side to match up with what your library expects. > >Also, according to >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore9 >8/HTML/_crt_signal.asp > > >SIGINT is not supported for win32 programs. I quote: >"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. " > >As for why you see the current behaviour, I'm a little mystified. > >Here's why: > >Firstly, here's a snippet of the output of a strace of kill -2 ><signals.exe pid> > > 2149 2816627 [main] kill 920 _kill: kill (3656, 2) > 1542 2818169 [main] kill 920 sig_send: pid 3656, signal 2, its_me 0 > 1387 2819556 [main] kill 920 getsem: pid 3656, ppid 3648, wait 1000, >initializing 0 > 1776 2821332 [main] kill 920 sig_send: Not waiting for sigcomplete. >its_me 0 signal 2 > 3817 2825149 [main] kill 920 sig_send: returning 0 from sending signal >2 > 2529 2827678 [main] kill 920 kill_worker: 0 = kill_worker (3656, 2) > >The getsem line is whats interesting: This is retrieving the semaphore >used to syncronise the signalling across process's. > >It succeeds! (I'm running a slightly modified cygwin here, which as the >patch at the end of this email shows (in combination with the source :}) >should always indicate if there is an error). It should always succeed. A non-cygwin app should have a cygwin stub associated with it. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: CGF: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 8:50 ` CGF: " Christopher Faylor @ 2002-01-07 15:00 ` Robert Collins 2002-01-07 15:45 ` Christopher Faylor 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-07 15:00 UTC (permalink / raw) To: cygwin ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> > >It succeeds! (I'm running a slightly modified cygwin here, which as the > >patch at the end of this email shows (in combination with the source :}) > >should always indicate if there is an error). > > It should always succeed. A non-cygwin app should have a cygwin stub > associated with it. Did you read further down? I realised that... I was interested if you thought my hypothesis was feasible. === So here's my best guess as to whats happening: When you hit CTRL-C, it propogates to signals.exe (handled as you expect) bash.exe (still attached to the console and gets handled via default signal handler - exit and terminate all subprocess's - which kills signals.exe) === Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: CGF: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 15:00 ` Robert Collins @ 2002-01-07 15:45 ` Christopher Faylor 2002-01-07 16:15 ` Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Christopher Faylor @ 2002-01-07 15:45 UTC (permalink / raw) To: cygwin On Tue, Jan 08, 2002 at 10:00:33AM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Christopher Faylor" <cgf@redhat.com> >> >It succeeds! (I'm running a slightly modified cygwin here, which as >the >> >patch at the end of this email shows (in combination with the source >:}) >> >should always indicate if there is an error). >> >> It should always succeed. A non-cygwin app should have a cygwin stub >> associated with it. > >Did you read further down? I realised that... I was interested if you >thought my hypothesis was feasible. Not in any great detail, no. I was addressing your apparent surprise over the fact that getsem was able to retrieve a semaphore. If you are looking for the "stub" code, it's in spawn_guts, around line 1078 in the current sources. I'd suggest tracing what happens there. cgf >=== >So here's my best guess as to whats happening: >When you hit CTRL-C, it propogates to >signals.exe (handled as you expect) >bash.exe (still attached to the console and gets handled via default >signal handler - exit and terminate all subprocess's - which kills >signals.exe) >=== > >Rob > > >-- >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/ -- cgf@redhat.com Red Hat, Inc. http://sources.redhat.com/ http://www.redhat.com/ -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: CGF: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 15:45 ` Christopher Faylor @ 2002-01-07 16:15 ` Robert Collins 2002-01-07 16:21 ` Christopher Faylor 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-07 16:15 UTC (permalink / raw) To: cygwin ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> > If you are looking for the "stub" code, it's in spawn_guts, around line > 1078 in the current sources. Line 1078 is the EOF for spawn.cc (current CVS). Is that correct? > I'd suggest tracing what happens there. Ys, in fact that was my next question :}. Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: CGF: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 16:15 ` Robert Collins @ 2002-01-07 16:21 ` Christopher Faylor 2002-01-07 16:43 ` Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Christopher Faylor @ 2002-01-07 16:21 UTC (permalink / raw) To: cygwin On Tue, Jan 08, 2002 at 11:15:11AM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Christopher Faylor" <cgf@redhat.com> >> If you are looking for the "stub" code, it's in spawn_guts, around >line >> 1078 in the current sources. > >Line 1078 is the EOF for spawn.cc (current CVS). Is that correct? Sorry. Misread my vim output. Line 805. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: CGF: please review my logic Re: bash/cmd CTRL-C problem... 2002-01-07 16:21 ` Christopher Faylor @ 2002-01-07 16:43 ` Robert Collins 2002-01-07 23:00 ` Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-07 16:43 UTC (permalink / raw) To: cygwin === ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> To: <cygwin@cygwin.com> Sent: Tuesday, January 08, 2002 11:21 AM Subject: Re: CGF: please review my logic Re: bash/cmd CTRL-C problem... > On Tue, Jan 08, 2002 at 11:15:11AM +1100, Robert Collins wrote: > >----- Original Message ----- > >From: "Christopher Faylor" <cgf@redhat.com> > >> If you are looking for the "stub" code, it's in spawn_guts, around > >line > >> 1078 in the current sources. > > > >Line 1078 is the EOF for spawn.cc (current CVS). Is that correct? > > Sorry. Misread my vim output. Line 805. No probs. If I read the code correctly, it loops 100 times waiting for * the child to exit * a signal to the stub to arrive * the child to indicate it is a cygwin process (via the spr event) Is that correct? If so, then I see two things to consider: 1) Presumably the CTRL C is arriving via exceptions.cc:(ctrl_c_handler). If so, then IMO we can safely disable this handler once the child is spawned, because a) The child has it's own handler b) This process will terminate as soon as the child does, or the child indicates it's a cygwin process That may introduce a race (fork(), exec(), CTRL-C, child actually starts) - but that could be address'd via queueing the signals until the child shows it's a cygwin process. IMO this race isn't an issue - what do you think? Disabling it could be done via a flag for exceptions.cc in_spawn_stub - so the other types of keyboard interrupt will still be serviced. 2) After 100 signals are sent to the stub, it looks like it will terminate. Was there a problem with hanging stubs that caused a non-infinite loop? Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-07 16:43 ` Robert Collins @ 2002-01-07 23:00 ` Robert Collins 2002-01-08 8:19 ` Christopher Faylor [not found] ` <027401c19855$68842f60$c51811ac@brokat.de> 0 siblings, 2 replies; 35+ messages in thread From: Robert Collins @ 2002-01-07 23:00 UTC (permalink / raw) To: Robert Collins, cygwin FWIW this patch (Chris where should I put the in_stub declaration) ==== Index: exceptions.cc =================================================================== RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v retrieving revision 1.103 diff -u -p -r1.103 exceptions.cc --- exceptions.cc 2002/01/05 22:25:34 1.103 +++ exceptions.cc 2002/01/08 06:54:23 @@ -890,11 +890,14 @@ setup_handler (int sig, void *handler, s #error "Need to supply machine dependent setup_handler" #endif +// Yeah, well. Where to put this? +bool in_stub = false; + /* CGF Keyboard interrupt handler. */ static BOOL WINAPI ctrl_c_handler (DWORD type) { - if (type == CTRL_LOGOFF_EVENT) + if (type == CTRL_LOGOFF_EVENT || (type == CTRL_C_EVENT && in_stub == true)) return TRUE; /* Return FALSE to prevent an "End task" dialog box from appearing Index: spawn.cc =================================================================== RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v retrieving revision 1.94 diff -u -p -r1.94 spawn.cc --- spawn.cc 2001/11/05 06:09:08 1.94 +++ spawn.cc 2002/01/08 06:54:25 @@ -314,6 +314,9 @@ av::unshift (const char *what, int conv) return 1; } +// From exceptions.cc +extern bool in_stub; // indicate when we are wrapping a non-cygwin program + static int __stdcall spawn_guts (HANDLE hToken, const char * prog_arg, const char *const *argv, const char *const envp[], int mode) @@ -804,8 +807,10 @@ spawn_guts (HANDLE hToken, const char * MALLOC_CHECK; if (mode == _P_OVERLAY) { + in_stub = true; // don't close on CTRL C. int nwait = 3; HANDLE waitbuf[3] = {pi.hProcess, signal_arrived, spr}; + // If spr is not triggered, it's not a cygwin process ? for (int i = 0; i < 100; i++) { switch (WaitForMultipleObjects (nwait, waitbuf, FALSE, INFINITE)) @@ -823,6 +828,7 @@ spawn_guts (HANDLE hToken, const char * reset_signal_arrived (); continue; case WAIT_OBJECT_0 + 2: + // SPR if (myself->ppid_handle) res |= EXIT_REPARENTING; if (!my_parent_is_alive ()) @@ -847,6 +853,7 @@ spawn_guts (HANDLE hToken, const char * } break; } + ForceCloseHandle (spr); @@ -874,6 +881,8 @@ spawn_guts (HANDLE hToken, const char * system_printf ("old hProcess %p, hProcess %p", oldh, myself->hProcess); } } + in_stub = false; // We're safely reparented now, or a cygwin wrapped win32 + // program has terminated. } ==== means that I get this output from the test programs: ============= Administrator@LIFELESSWKS ~/t $ ./signals.exe >>> signals: Waiting now... >>>>>> myclass CPP: Installing atexit handler... >>>>>> myclass CPP: Installing signal handler... >>>>>> myclass CPP: Falling asleep... ............................................................ >>> signals: Signal SIGINT=2 received ...................................... >>> signals: Finished waiting now... >>> signals: Forwarding CTRL_BREAK_EVENT to the child process... .. >>>>>> myclass CPP: SIGBREAK caught... >>>>>> myclass CPP: Process terminating... ================= So it looks like it solves it. I've noticed no side effects either. Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-07 23:00 ` Robert Collins @ 2002-01-08 8:19 ` Christopher Faylor 2002-01-08 14:16 ` Robert Collins [not found] ` <027401c19855$68842f60$c51811ac@brokat.de> 1 sibling, 1 reply; 35+ messages in thread From: Christopher Faylor @ 2002-01-08 8:19 UTC (permalink / raw) To: cygwin On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote: >FWIW this patch (Chris where should I put the in_stub declaration) There is already an indicator that an execed process is running -- hExeced, so I don't think you need the 'in_stub' thing. However, it seems to me that this solution is racy. If a person types CTRL-C during process startup, it's possible that a cygwin process will never see a true cygwin signal. Hmm. I guess this race is already in signal_exit, in fact. I have to fix that. Regardless, it is not always the correct behavior for CTRL-C just do the "default thing". If the execed process is supposed to be ignoring SIGINT then it isn't right for the process to exit. Also, your change seems to make no distinction between a spawned and execed process. It looks like if the user had called spawn, a CTRL-C would just cause the parent process to die. cgf >==== >Index: exceptions.cc >=================================================================== >RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v >retrieving revision 1.103 >diff -u -p -r1.103 exceptions.cc >--- exceptions.cc 2002/01/05 22:25:34 1.103 >+++ exceptions.cc 2002/01/08 06:54:23 >@@ -890,11 +890,14 @@ setup_handler (int sig, void *handler, s > #error "Need to supply machine dependent setup_handler" > #endif > >+// Yeah, well. Where to put this? >+bool in_stub = false; >+ > /* CGF Keyboard interrupt handler. */ > static BOOL WINAPI > ctrl_c_handler (DWORD type) > { >- if (type == CTRL_LOGOFF_EVENT) >+ if (type == CTRL_LOGOFF_EVENT || (type == CTRL_C_EVENT && in_stub == >true)) > return TRUE; > > /* Return FALSE to prevent an "End task" dialog box from appearing >Index: spawn.cc >=================================================================== >RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v >retrieving revision 1.94 >diff -u -p -r1.94 spawn.cc >--- spawn.cc 2001/11/05 06:09:08 1.94 >+++ spawn.cc 2002/01/08 06:54:25 >@@ -314,6 +314,9 @@ av::unshift (const char *what, int conv) > return 1; > } > >+// From exceptions.cc >+extern bool in_stub; // indicate when we are wrapping a non-cygwin >program >+ > static int __stdcall > spawn_guts (HANDLE hToken, const char * prog_arg, const char *const >*argv, > const char *const envp[], int mode) >@@ -804,8 +807,10 @@ spawn_guts (HANDLE hToken, const char * > MALLOC_CHECK; > if (mode == _P_OVERLAY) > { >+ in_stub = true; // don't close on CTRL C. > int nwait = 3; > HANDLE waitbuf[3] = {pi.hProcess, signal_arrived, spr}; >+ // If spr is not triggered, it's not a cygwin process ? > for (int i = 0; i < 100; i++) > { > switch (WaitForMultipleObjects (nwait, waitbuf, FALSE, >INFINITE)) >@@ -823,6 +828,7 @@ spawn_guts (HANDLE hToken, const char * > reset_signal_arrived (); > continue; > case WAIT_OBJECT_0 + 2: >+ // SPR > if (myself->ppid_handle) > res |= EXIT_REPARENTING; > if (!my_parent_is_alive ()) >@@ -847,6 +853,7 @@ spawn_guts (HANDLE hToken, const char * > } > break; > } >+ > > ForceCloseHandle (spr); > >@@ -874,6 +881,8 @@ spawn_guts (HANDLE hToken, const char * > system_printf ("old hProcess %p, hProcess %p", oldh, >myself->hProcess); > } > } >+ in_stub = false; // We're safely reparented now, or a cygwin >wrapped win32 >+ // program has terminated. > > } >==== > >means that I get this output from the test programs: >============= >Administrator@LIFELESSWKS ~/t >$ ./signals.exe > >>>> signals: Waiting now... >>>>>>> myclass CPP: Installing atexit handler... > >>>>>>> myclass CPP: Installing signal handler... >>>>>>> myclass CPP: Falling asleep... >............................................................ >>>> signals: Signal SIGINT=2 received >...................................... >>>> signals: Finished waiting now... > >>>> signals: Forwarding CTRL_BREAK_EVENT to the child process... >.. >>>>>>> myclass CPP: SIGBREAK caught... >>>>>>> myclass CPP: Process terminating... > > >================= > >So it looks like it solves it. I've noticed no side effects either. > >Rob > > >-- >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/ -- cgf@redhat.com Red Hat, Inc. http://sources.redhat.com/ http://www.redhat.com/ -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 8:19 ` Christopher Faylor @ 2002-01-08 14:16 ` Robert Collins 2002-01-08 16:39 ` Christopher Faylor 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-08 14:16 UTC (permalink / raw) To: cygwin ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> > On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote: > >FWIW this patch (Chris where should I put the in_stub declaration) > > There is already an indicator that an execed process is running -- > hExeced, so I don't think you need the 'in_stub' thing. No, hExeced is set far too early... There is a very narrow window where we want to ignore CTRL-C. > However, it seems to me that this solution is racy. If a person types > CTRL-C during process startup, it's possible that a cygwin process will > never see a true cygwin signal. Hmm. I guess this race is already > in signal_exit, in fact. I have to fix that. Yes there is. I asked for thoughts, but got none :}. However, note the requirements to drop the signal: * The process startup must be in _P_OVERLAY mode. * The new process must have successfully been created. * Their must be no cygwin parent to the spawning process, or the spawning process must be the top of the process group. * The new process must not have signalled it's creation back to us. > Regardless, it is not always the correct behavior for CTRL-C just do > the "default thing". If the execed process is supposed to be ignoring > SIGINT then it isn't right for the process to exit. Hangon, look closer. If the execed process is a *cygwin* process, then my patch makes no difference - the stub is about to quit no matter what, and from a POSIX point of view, already has! If the execed process is not a cygwin process, then it will handle (or not) CTRL-C itself. We should *not* force quit it when the stub recieves CTRL-C. I don't reinstate default behaviour, we simply ignore the keyboard generated CTRL-C which we know that the non-cygwin child has already recieved. > Also, your change seems to make no distinction between a spawned and > execed process. It looks like if the user had called spawn, a CTRL-C > would just cause the parent process to die. No, if the user had called spawn, with mode != _P_OVERLAY, then this patch makes no difference. If the user had called spawn with mode == _P_OVERLAY and it's spawning a cygwin program then the user will notice no difference, or worst case a _perfectly timed_ CTRL-C is ignored. (Note: Ctrl-Break is not altered). If the user had called spawn with mode == _P_OVERLAY and it's spawning a non cygwin program then the user will notice no difference - the non cygwin program will handle it's own CTRL-C. -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 14:16 ` Robert Collins @ 2002-01-08 16:39 ` Christopher Faylor 2002-01-08 16:43 ` Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Christopher Faylor @ 2002-01-08 16:39 UTC (permalink / raw) To: cygwin On Wed, Jan 09, 2002 at 09:16:55AM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Christopher Faylor" <cgf@redhat.com> > > >> On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote: >> >FWIW this patch (Chris where should I put the in_stub declaration) >> >> There is already an indicator that an execed process is running -- >> hExeced, so I don't think you need the 'in_stub' thing. > >No, hExeced is set far too early... There is a very narrow window where >we want to ignore CTRL-C. We want to deal with CTRL-C as soon as the process enters its "stub state". That's when hExeced is set. >>However, it seems to me that this solution is racy. If a person types >>CTRL-C during process startup, it's possible that a cygwin process will >>never see a true cygwin signal. Hmm. I guess this race is already in >>signal_exit, in fact. I have to fix that. > >Yes there is. I asked for thoughts, but got none :}. Yes, as I mentioned, I wasn't actually interested in debugging this myself but I would investigate patches. >However, note the requirements to drop the signal: >* The process startup must be in _P_OVERLAY mode. I completely missed this before. Sorry. >* The new process must have successfully been created. It wouldn't be much of a process if it didn't exist, I guess. >* Their must be no cygwin parent to the spawning process, or the >spawning process must be the top of the process group. Yes. It must be at the top of a process group. Period. >* The new process must not have signalled it's creation back to us. I don't think this is right, actually. You basically don't want the stub to *ever* send a CTRL-C in your scenario. I don't see why it matters that the subprocess has been reparented. You especially don't want the parent to be responding to CTRL-Cs when the child has indicated "Yep! I'm a cygwin process." >> Regardless, it is not always the correct behavior for CTRL-C just do >> the "default thing". If the execed process is supposed to be ignoring >> SIGINT then it isn't right for the process to exit. > >Hangon, look closer. >If the execed process is a *cygwin* process, then my patch makes no >difference - the stub is about to quit no matter what, and from a POSIX >point of view, already has! You're right. I did need to look closer. However, IMO, there's a race here. It's possible that killing other members of the process group is the right thing to do if the child is still initializing and is unable to handle the CTRL/C correctly. Your patch eliminates that capability so it may mean that CTRL-C's are lost. >If the execed process is not a cygwin process, then it will handle (or >not) CTRL-C itself. We should *not* force quit it when the stub recieves >CTRL-C. Oddly enough, that is behavior that I reinstated when I had eliminated it for a while because people complained that they couldn't kill their processes. If you don't do that then GUI windows apps don't go away when you hit CTRL-C, IIRC. This is the usual cygwin damned if you do/damned if you don't scenario. >I don't reinstate default behaviour, we simply ignore the keyboard >generated CTRL-C which we know that the non-cygwin child has already >recieved. We know that the child will receive or is about to receive it but we don't know that the child is about to do the right thing as a result of receiving it. >> Also, your change seems to make no distinction between a spawned and >> execed process. As I mentioned, this observation was just completely wrong. :-( I have to think about the race issues here. It seems like you can't get away without some kind of additional communication between the parent and the child. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 16:39 ` Christopher Faylor @ 2002-01-08 16:43 ` Robert Collins 2002-01-08 16:55 ` Christopher Faylor 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-08 16:43 UTC (permalink / raw) To: cygwin ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> > >* The new process must not have signalled it's creation back to us. > > I don't think this is right, actually. You basically don't want the stub > to *ever* send a CTRL-C in your scenario. I don't see why it matters that > the subprocess has been reparented. You especially don't want the parent to > be responding to CTRL-Cs when the child has indicated "Yep! I'm a cygwin > process." What I meant was, that once the child has signaled it's a cygwin process, we terminate the stub immediately anyway. But yes, perhaps we should not re-enable CTRL-C processing. > >Hangon, look closer. > >If the execed process is a *cygwin* process, then my patch makes no > >difference - the stub is about to quit no matter what, and from a POSIX > >point of view, already has! > > You're right. I did need to look closer. > > However, IMO, there's a race here. It's possible that killing other > members of the process group is the right thing to do if the child is > still initializing and is unable to handle the CTRL/C correctly. Your > patch eliminates that capability so it may mean that CTRL-C's are lost. > > >If the execed process is not a cygwin process, then it will handle (or > >not) CTRL-C itself. We should *not* force quit it when the stub recieves > >CTRL-C. > > Oddly enough, that is behavior that I reinstated when I had eliminated > it for a while because people complained that they couldn't kill their > processes. If you don't do that then GUI windows apps don't go away > when you hit CTRL-C, IIRC. > > This is the usual cygwin damned if you do/damned if you don't scenario. Hmm. Well CTRL-C and CTRL-BREAK are identified separately. I'll go have a browse of the lists I guess. > >I don't reinstate default behaviour, we simply ignore the keyboard > >generated CTRL-C which we know that the non-cygwin child has already > >recieved. > > We know that the child will receive or is about to receive it but we > don't know that the child is about to do the right thing as a result > of receiving it. True. The issue IMO is whether we assume the child will do the right thing, or whether we assume the child won't. If it's a cygwin child it'll do the right thing after being reparented. If it's a non-cygwin child it'll do the right thing on it's own. > >> Also, your change seems to make no distinction between a spawned and > >> execed process. > > As I mentioned, this observation was just completely wrong. :-( > > I have to think about the race issues here. It seems like you can't get > away without some kind of additional communication between the parent and > the child. True. The problem is that we can't communicate with non-cygwin children. So there will always be a window (from when a process is created to when we find out it's a cygwin process) where we have to guess :}. Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 16:43 ` Robert Collins @ 2002-01-08 16:55 ` Christopher Faylor 2002-01-08 16:57 ` Robert Collins 0 siblings, 1 reply; 35+ messages in thread From: Christopher Faylor @ 2002-01-08 16:55 UTC (permalink / raw) To: cygwin On Wed, Jan 09, 2002 at 11:43:41AM +1100, Robert Collins wrote: >>I have to think about the race issues here. It seems like you can't >>get away without some kind of additional communication between the >>parent and the child. > >True. The problem is that we can't communicate with non-cygwin >children. I think basically you just have to ensure that the stub doesn't exit on CTRL-C. I can't think of a scenario where that's desireable now. I think you could get just about the same behavior that you're describing if you just blocked SIGINT prior to calling CreateProcess. However, you've uncovered another problem in that it is possible for both the stub and the child to fire off a kill() resulting in double sending of CTRL-C during an exec(). So, I think the easiest fix for the current problem is just to do a 'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring the previous signal handler if the CreateProcess fails. That doesn't solve the double sending of CTRL-Cs but that's a separate problem, I think. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 16:55 ` Christopher Faylor @ 2002-01-08 16:57 ` Robert Collins 2002-01-08 17:13 ` Christopher Faylor 0 siblings, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-08 16:57 UTC (permalink / raw) To: cygwin === ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> > So, I think the easiest fix for the current problem is just to do a > 'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring > the previous signal handler if the CreateProcess fails. You do realise, that thats what I've done, but via the more efficient way of returning TRUE to the signal. > That doesn't solve the double sending of CTRL-Cs but that's a separate > problem, I think. Yes. -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 16:57 ` Robert Collins @ 2002-01-08 17:13 ` Christopher Faylor 2002-01-08 17:16 ` Robert Collins 2002-01-08 17:46 ` Charles Wilson 0 siblings, 2 replies; 35+ messages in thread From: Christopher Faylor @ 2002-01-08 17:13 UTC (permalink / raw) To: cygwin On Wed, Jan 09, 2002 at 11:57:04AM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Christopher Faylor" <cgf@redhat.com> > >> So, I think the easiest fix for the current problem is just to do a >> 'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring >> the previous signal handler if the CreateProcess fails. > >You do realise, that thats what I've done, but via the more efficient >way of returning TRUE to the signal. Sure. I understand what you are doing. It usually only takes me a couple of tries to "get it". I'm specifically trying not to do the "TRUE" thing, though, since AFAICT it isn't always appropriate. For the record, I really appreciate your tracking this down. I finally understand the issues here. These issues have been around for a long time and the problems that you uncovered are probably responsible for some longstanding cygwin strangeness. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 17:13 ` Christopher Faylor @ 2002-01-08 17:16 ` Robert Collins 2002-01-09 18:46 ` Christopher Faylor 2002-01-08 17:46 ` Charles Wilson 1 sibling, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-08 17:16 UTC (permalink / raw) To: cygwin ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> > On Wed, Jan 09, 2002 at 11:57:04AM +1100, Robert Collins wrote: > >----- Original Message ----- > >From: "Christopher Faylor" <cgf@redhat.com> > > > >> So, I think the easiest fix for the current problem is just to do a > >> 'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring > >> the previous signal handler if the CreateProcess fails. > > > >You do realise, that thats what I've done, but via the more efficient > >way of returning TRUE to the signal. > > Sure. I understand what you are doing. It usually only takes me a > couple of tries to "get it". :}. Lol. > I'm specifically trying not to do the "TRUE" thing, though, since AFAICT > it isn't always appropriate. If you want to SIG_IGN the signal, then it is: "When a CTRL+C signal is received, the control handler returns TRUE, indicating that it has handled the signal. Doing this prevents other control handlers from being called." (note that this is within this process only). > For the record, I really appreciate your tracking this down. I finally > understand the issues here. These issues have been around for a long time > and the problems that you uncovered are probably responsible for some > longstanding cygwin strangeness. No probs. Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 17:16 ` Robert Collins @ 2002-01-09 18:46 ` Christopher Faylor 2002-01-09 19:42 ` Christopher Faylor 2002-01-09 23:59 ` Robert Collins 0 siblings, 2 replies; 35+ messages in thread From: Christopher Faylor @ 2002-01-09 18:46 UTC (permalink / raw) To: cygwin On Wed, Jan 09, 2002 at 12:16:04PM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Christopher Faylor" <cgf@redhat.com> >>I'm specifically trying not to do the "TRUE" thing, though, since >>AFAICT it isn't always appropriate. > >If you want to SIG_IGN the signal, then it is: "When a CTRL+C signal is >received, the control handler returns TRUE, indicating that it has >handled the signal. Doing this prevents other control handlers from >being called." (note that this is within this process only). I was going back over this thread before checking in a change to see if I'd missed something. I just realized that I didn't address this concern. Don't know if it matters but... The difference between the SIG_IGN way and the "return TRUE" way is that the SIG_IGN way stops the current process from responding to a cygwin signal but still lets it respond to a Windows "signal". That means that the code in ctrl_c_handle can do its job, if it has to. If we always "return TRUE" in the exec case, then there will be some situations where the SIGINT is not delivered to the rest of the process group since the code in ctrl_c_handler would be short circuited. My SIG_IGN "solution" is wrong, too, though. The SIG_IGN would be inherited by the exec'ed process. Then the execed process would never see a cygwin SIGINT signal. So, I made a minor change to the signal handling code to ignore SIGINTs when the program is a stub. I also thought that I'd brilliantly worked around the potential intialization signal race but after a night's sleep I realize that is not the case. Bleah. I really don't want to use a mutex for such a rare corner case. Btw, if I fix this, I may well fix a problem with CTRL-C and fork() that I've been noticing for years, too. Or, at least I'll be able to convince myself its fixed until the next time I see the problem. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-09 18:46 ` Christopher Faylor @ 2002-01-09 19:42 ` Christopher Faylor 2002-01-09 23:59 ` Robert Collins 1 sibling, 0 replies; 35+ messages in thread From: Christopher Faylor @ 2002-01-09 19:42 UTC (permalink / raw) To: cygwin There is a snapshot up there now which seems to work ok. Again, many thanks to Robert Collins for tracking this down. Although I said I wasn't overly interested in tracking this down myself, I was interested in seeing the lessening in email traffic that I hope this fix engenders. I do expect that, when this cygwin DLL is released, there could be a reaction from another, previously silent camp who relied on the old CTRL-C behavior. I guess it will be interesting to see if that is the case. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-09 18:46 ` Christopher Faylor 2002-01-09 19:42 ` Christopher Faylor @ 2002-01-09 23:59 ` Robert Collins 2002-01-10 7:53 ` Christopher Faylor 1 sibling, 1 reply; 35+ messages in thread From: Robert Collins @ 2002-01-09 23:59 UTC (permalink / raw) To: cygwin === ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> To: <cygwin@cygwin.com> Sent: Thursday, January 10, 2002 1:46 PM Subject: Re: bash/cmd CTRL-C problem... > On Wed, Jan 09, 2002 at 12:16:04PM +1100, Robert Collins wrote: > >----- Original Message ----- > >From: "Christopher Faylor" <cgf@redhat.com> > >>I'm specifically trying not to do the "TRUE" thing, though, since > >>AFAICT it isn't always appropriate. > > > >If you want to SIG_IGN the signal, then it is: "When a CTRL+C signal is > >received, the control handler returns TRUE, indicating that it has > >handled the signal. Doing this prevents other control handlers from > >being called." (note that this is within this process only). > > I was going back over this thread before checking in a change to see if > I'd missed something. > > I just realized that I didn't address this concern. Don't know if it > matters but... > > The difference between the SIG_IGN way and the "return TRUE" way is > that the SIG_IGN way stops the current process from responding to > a cygwin signal but still lets it respond to a Windows "signal". That > means that the code in ctrl_c_handle can do its job, if it has to. Huh? I actually did the reverse - returning TRUE only prevented responding to a windows signal, but allowed responding to a cygwin signal. This meant that 'kill -2 stubpid' from another shell would kill the stub and it's spawned programs, which may alleviate some of the 'CTRL-C doesn't work for me now' grief that you rightly expect. I mention this because IMO the strange behaviour is due to user expectation of ^C behaviour - not signal behaviour. > If we always "return TRUE" in the exec case, then there will be some > situations where the SIGINT is not delivered to the rest of the process > group since the code in ctrl_c_handler would be short circuited. I don't believe that is the case: Every console process attached to that console independently recieves the windows signal. Only one has been disabled. So the execing process's children will still recieve the windows signals and the cygwin signals. > My SIG_IGN "solution" is wrong, too, though. The SIG_IGN would be > inherited by the exec'ed process. Then the execed process would never > see a cygwin SIGINT signal. Yes. I still believe that return TRUE is a good solution... but if you've solved the obvious behaviour I'll be quite now :}. > Btw, if I fix this, I may well fix a problem with CTRL-C and fork() that > I've been noticing for years, too. Or, at least I'll be able to convince > myself its fixed until the next time I see the problem. Cool. Rob -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-09 23:59 ` Robert Collins @ 2002-01-10 7:53 ` Christopher Faylor 0 siblings, 0 replies; 35+ messages in thread From: Christopher Faylor @ 2002-01-10 7:53 UTC (permalink / raw) To: cygwin On Thu, Jan 10, 2002 at 06:59:54PM +1100, Robert Collins wrote: >> I was going back over this thread before checking in a change to see if >> I'd missed something. >> >> I just realized that I didn't address this concern. Don't know if it >> matters but... >> >> The difference between the SIG_IGN way and the "return TRUE" way is >> that the SIG_IGN way stops the current process from responding to >> a cygwin signal but still lets it respond to a Windows "signal". That >> means that the code in ctrl_c_handle can do its job, if it has to. > >Huh? I actually did the reverse - returning TRUE only prevented >responding to a windows signal, but allowed responding to a cygwin >signal. Yep. Wrong behavior. The stub should respond to windows signals while the child is initializing. Remember this discussion? >>If we always "return TRUE" in the exec case, then there will be some >>situations where the SIGINT is not delivered to the rest of the process >>group since the code in ctrl_c_handler would be short circuited. > >I don't believe that is the case: Every console process attached to >that console independently recieves the windows signal. Only one has >been disabled. So the execing process's children will still recieve >the windows signals and the cygwin signals. The newly executed subprocess may not have yet set up ctrl_c_handler so it will not do anything but die when CTRL-C comes in. The stub will ignore the CTRL-C. That means that the rest of the processes in the process group will not receive a CTRL-C. >> My SIG_IGN "solution" is wrong, too, though. The SIG_IGN would be >> inherited by the exec'ed process. Then the execed process would never >> see a cygwin SIGINT signal. > >Yes. I still believe that return TRUE is a good solution... but if >you've solved the obvious behaviour I'll be quite now :}. I guess I'm having a hard time understanding why I couldn't just say "race" and have you understand that there is a race but I'll stop now, too. cgf -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: bash/cmd CTRL-C problem... 2002-01-08 17:13 ` Christopher Faylor 2002-01-08 17:16 ` Robert Collins @ 2002-01-08 17:46 ` Charles Wilson 1 sibling, 0 replies; 35+ messages in thread From: Charles Wilson @ 2002-01-08 17:46 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > For the record, I really appreciate your tracking this down. I finally > understand the issues here. These issues have been around for a long time > and the problems that you uncovered are probably responsible for some > longstanding cygwin strangeness. Ditto. For he's a jolly good fellow, for he's a jolly good fellow.... --Chuck -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <027401c19855$68842f60$c51811ac@brokat.de>]
[parent not found: <03a901c1989b$69c8e190$0200a8c0@lifelesswks>]
* Re: bash/cmd CTRL-C problem... [not found] ` <03a901c1989b$69c8e190$0200a8c0@lifelesswks> @ 2002-01-09 0:14 ` Michael Rumpf 0 siblings, 0 replies; 35+ messages in thread From: Michael Rumpf @ 2002-01-09 0:14 UTC (permalink / raw) To: Robert Collins; +Cc: cygwin > Did you mean to take this off-list? My preference is to keep discussions > on-list where possible. Sorry, hadn't looked at the To: field when replying... > ----- Original Message ----- > From: "Michael Rumpf" <michael@rumpfonline.de> > To: "Robert Collins" <robert.collins@itdomain.com.au> > Sent: Wednesday, January 09, 2002 2:01 AM > Subject: Re: bash/cmd CTRL-C problem... > > > > The output is looking as if it is working correctly now. Great work > !!!! > > > > If this is accepted which module needs to be updated ? Is it the bash > only > > or does the code belong to the cygwin DLL ? And what are the public > release > > plans for those modules, i.e. when do you expect to see this hit any > stable > > module release...? > > It's a cygwin1.dll change, nothing to do with bash. Once Chris and I > agree on the minor details to make this happen, it'll be available in > snapshots within a day or two. Then the next release will have the code > > > The fact is that our integration team which does provide the > infrastructure > > for the build process will not accept any other version than an > officially > > released one... > > *shrug*. I'm pretty sure that a new release won't be rushed out to fix a > minor non-security related bug. A snapshot is perfect. I just don't think that our integration team would take the effort to build cygwin from source ... Michael -- 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2002-01-10 15:53 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-19 23:48 bash/cmd CTRL-C problem Michael Rumpf 2001-12-20 1:28 ` Michael Rumpf 2001-12-21 2:17 ` Michael Rumpf 2001-12-21 7:27 ` Corinna Vinschen 2001-12-21 8:46 ` Michael Rumpf 2002-01-04 3:51 ` Michael Rumpf 2002-01-04 9:04 ` Christopher Faylor 2002-01-07 0:46 ` Michael Rumpf 2002-01-07 1:10 ` Robert Collins 2002-01-07 1:58 ` Michael Rumpf 2002-01-07 2:30 ` Robert Collins 2002-01-07 2:56 ` Michael Rumpf 2002-01-07 5:15 ` CGF: please review my logic " Robert Collins 2002-01-07 6:18 ` Michael Rumpf 2002-01-07 8:50 ` CGF: " Christopher Faylor 2002-01-07 15:00 ` Robert Collins 2002-01-07 15:45 ` Christopher Faylor 2002-01-07 16:15 ` Robert Collins 2002-01-07 16:21 ` Christopher Faylor 2002-01-07 16:43 ` Robert Collins 2002-01-07 23:00 ` Robert Collins 2002-01-08 8:19 ` Christopher Faylor 2002-01-08 14:16 ` Robert Collins 2002-01-08 16:39 ` Christopher Faylor 2002-01-08 16:43 ` Robert Collins 2002-01-08 16:55 ` Christopher Faylor 2002-01-08 16:57 ` Robert Collins 2002-01-08 17:13 ` Christopher Faylor 2002-01-08 17:16 ` Robert Collins 2002-01-09 18:46 ` Christopher Faylor 2002-01-09 19:42 ` Christopher Faylor 2002-01-09 23:59 ` Robert Collins 2002-01-10 7:53 ` Christopher Faylor 2002-01-08 17:46 ` Charles Wilson [not found] ` <027401c19855$68842f60$c51811ac@brokat.de> [not found] ` <03a901c1989b$69c8e190$0200a8c0@lifelesswks> 2002-01-09 0:14 ` Michael Rumpf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).