From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2571 invoked by alias); 7 Jan 2002 17:06:32 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 2430 invoked from network); 7 Jan 2002 17:06:22 -0000 Received: from unknown (HELO mail-green.research.att.com) (135.207.30.103) by sources.redhat.com with SMTP; 7 Jan 2002 17:06:22 -0000 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id EDA791E009; Mon, 7 Jan 2002 12:06:20 -0500 (EST) Received: from research.att.com ([135.207.253.31]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id MAA21535; Mon, 7 Jan 2002 12:03:10 -0500 (EST) Message-ID: <3C39D622.9C5C8279@research.att.com> Date: Mon, 07 Jan 2002 09:06:00 -0000 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Rumpf Cc: cygwin@cygwin.com Subject: Re: bash/cmd CTRL-C problem... References: <3C39C8C1.6B45A3FB@research.att.com> <02b901c19798$5f35d070$c51811ac@brokat.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00309.txt.bz2 Michael, I agree that this behavior should be considered a bug since the bash cygwin behavior differs from bash behavior on other unix platforms. This has caused headaches for our project too. Greg. For the record, here is a very simple java test program that I sent to Troy when we discussed this problem last November. This program simply intercepts CTL-C and runs a shutdown hook prior to shutting down the Java VM. It works fine under cmd.exe and cygwin ash, but does not work under cygwin bash. public static void main(String[] argv) { Runtime.getRuntime().addShutdownHook(new Thread(new Shutdown(), "Shutdown")); Object waitingPlace = new Object(); synchronized(waitingPlace) { try { waitingPlace.wait(); } catch (InterruptedException e) {} } } private static class Shutdown implements Runnable { public void run() { System.out.println("ProcessManager - shutting down..."); } } } Michael Rumpf wrote: > Hi Gregory, > > thanks for the info. > > > This may be related to a problem that prevents the cygwin bash shell > > from propagating ^C to Win32 child processes. This is a bug/feature of > > the cygwin bash shell. See the threads at > > http://cygwin.com/ml/cygwin/2001-11/msg01579.html and > > http://www.cygwin.com/ml/cygwin/2001-08/msg01111.html for discussions of > > this problem. I've also included some message excerpts that didn't make > > it onto the cywin mailing list that provide some insight into the > > rationale for the bug/feature. > > There seem to be two problems/features: > 1. CTRL-C is not propagated to child processes. > 2. Execution of the application is not continued after the CTRL-C signal is > handled. > > Both problems seem to happen only when applications are linked against the > MS crt libs and run under the bash. > However, I can't believe that my problem (2nd) is seen as a feature. The > bash behaves differently under Win32 and under any UNIX environment I'm > using here (AIX, HPUX, Solaris, Linux). There I can just press CTRL-C and > the main/parent process receives a SIGINT, sets a flag in the signal > handler, continues execution at the point where it was interrupted and thus > causes the main process to send CTRL-BREAK events to its children. For this > to happen the application code must continue its execution rather than > stopping after handling the signal. The correct behaviour can also be seen > in cmd.exe and I believe in bash when your app is linked against the cygwin > libs (I did not try this yet because it is no option for our application > server launcher program). So the only case where the behaviour is different > is when you have an app linked against the MS crt libs which is running > under the bash. I wouldn't see this as a feature I would see this as a > bug.... > > Michael > > > Greg. > > > > Charlie wrote: > > > > > Hi, > > > > > > I submitted some additional posts, along with some stuff from another > guy > > > that had a pretty good clue what was going on. search for my email > address > > > as I haven't posted that much to the list so you shouldn't have to pick > > > through too much. I'd send you a copy but its not handy at the moment. > Let > > > me know if you can't find it and I'll see if I can't dig some of them > up. > > > > > > The bottom line is that cygwin/bash executes win32 executables by > spawning > > > off another bash shell and running the win32 app inside it. Any signals > > > generated are received by the bash shell and not the win32 app. If your > > > running Win2k run the task manager, compare to the "ps" command in > cygwin, > > > look at the process IDs, and you'll see this. So the control C kills the > > > bash shell and the win32 app at the same time, hence any > cleanup/destructors > > > never get to finish, assuming they even got to start. > > > > > > According to the guy I was exchanging info with, who knew a lot more > about > > > the internals of cygwin, this is a feature that actually lets cygwin run > DOS > > > applications, and is not something to be "fixed". Given my lack of > knowledge > > > of the internals, I can argue with that :-) > > > > > > VR, Charlie > > > > > > > > > > > Troy Noble wrote: > > > > > And just to be clear, you did set CYGWIN=tty before starting bash per > the > > > FAQ? > > > I just have to double check to be sure. If you already know this, just > > > ignore. > > > The best way to ensure this is to start a cmd.exe, type set CYGWIN=tty > or > > > set CYGWIN= as desired, and then \cygwin\bin\bash.exe. Or you can set > > > CYGWIN > > > in your NT environment, logout, and login. Or edit your cygwin.bat file > to > > > do > > > it before it invokes "bash --login -i". Any of those options work > equally > > > well. > > > The key is that you do not want to set it in your .bashrc because by > then it > > > is > > > too late because the process initialization has already been done. The > FAQ > > > talks > > > about this some more. > > > > > > > Michael wrote: > > > > > Hi Corinna, > > > > > > thanks for the answer. No I haven't tried such an option as I must admit > > > that I don't know about it. > > > I will search for it in the docs and try to play around with it... > > > > > > Michael > > > > > > > > > On Fri, 2001-12-21 at 16:24, Corinna Vinschen wrote: > > > > On Fri, Dec 21, 2001 at 11:09:05AM +0100, Michael Rumpf wrote: > > > > > Am I the only one having problems with this, or is this simply the > wrong > > > > > list to ask a question about the Cygwin bash... ?? > > > > > > > > Nah, this is the right list. Nobody has an answer, though. > > > > > > > > Did you try `CYGWIN=... tty ...' setting? > > > > > > > > Corinna > > > > > > > > > > > > > > Michael > > > > > > > > > > ----- Original Message ----- > > > > > From: "Michael Rumpf" > > > > > To: > > > > > Sent: Thursday, December 20, 2001 10:11 AM > > > > > Subject: Re: bash/cmd CTRL-C problem... > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > sorry for following up myself, but I found out that Cygwin equally > handles > > > > > > CTRL-BREAK and CTRL-C by sending a SIGINT to the process. > > > > > > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last > sentence). > > > > > > This seems to be the source of the problem. > > > > > > CTRL-BREAK under the cmd shell terminates the process after > handling the > > > > > > signal without further executing any code. The bad thing is that > under > > > > > bash > > > > > > the same behaviour follows from pressing CTRL-BREAK _and_ CTRL-C > !! > > > > > > > > > > > > If this is a design issue, can someone please explain what the > reasons > > > > > > are... > > > > > > > > > > > > We have an application that forks other processes. The main thread > is > > > > > > waiting for the signal handler to return in order to cleanly stop > the > > > > > child > > > > > > processes. By just stopping the parent process the child processes > keep > > > > > > running and I have to kill them manually each time I press CTRL-C. > The > > > > > same > > > > > > application is working fine under windows cmd shell and bash under > Linux , > > > > > > HP-UX 10/11, AIX4.x, and SunOS 2.5+... > > > > > > > > > > > > Please help, I don't want to use the stupid windows cmd shell.... > ;-) > > > > > > > > > > > > Michael > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Michael Rumpf" > > > > > > To: > > > > > > Sent: Thursday, December 20, 2001 7:47 AM > > > > > > Subject: bash/cmd CTRL-C problem... > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm new to the list and I don't know if this problem is already > solved, > > > > > > but > > > > > > > I couldn't find a hint neither on the archives nor on the FAQ or > > > > > somewhere > > > > > > > else on the net. > > > > > > > > > > > > > > My problem is related to bash/cmd and signal handling. > > > > > > > In my app I installed a signal handler for SIGINT. The app is > going into > > > > > a > > > > > > > wait loop and waiting for the exit flag from the signal handler > to be > > > > > set. > > > > > > > > > > > > > > When pressing CTRL-C in the windows cmd shell the application > continues > > > > > > > normally after the signal handler has been caught. Under bash > the signal > > > > > > > handler is also correctly called, but after that the app is > exiting > > > > > > > immediatly, i.e. not continuing with the code. > > > > > > > Here is the source: > > > > > > > > > > > > > > > > > > > > > > > > > > //////////////////////////////////////////////////////////////////////////// > > > > > > > ///////////////// > > > > > > > #include > > > > > > > #include > > > > > > > #include > > > > > > > > > > > > > > bool loop = true; > > > > > > > > > > > > > > extern "C" void signalHandler(int sig) > > > > > > > { > > > > > > > switch( sig ) > > > > > > > { > > > > > > > case SIGINT: // == 2 > > > > > > > printf("SIGINT=%d\n",sig); > > > > > > > break; > > > > > > > default: > > > > > > > printf("default=%d\n",sig); > > > > > > > break; > > > > > > > }; > > > > > > > loop=false; > > > > > > > } > > > > > > > > > > > > > > int main(int argc, char* argv[]) > > > > > > > { > > > > > > > if (signal( SIGINT , signalHandler ) == SIG_ERR) > > > > > > > return -1; > > > > > > > printf("### ctrlbreak: Waiting now...\n"); > > > > > > > while(loop) > > > > > > > Sleep ((DWORD) 1000) ; > > > > > > > printf("### ctrlbreak: Finished waiting now...\n"); > > > > > > > return 0; > > > > > > > } > > > > > > > > > > > > > > > > > > > //////////////////////////////////////////////////////////////////////////// > > > > > > > ///////////////// > > > > > > > > > > > > > > Here the the output of the app under Win2K/bash: > > > > > > > // bash 2.05a-2 > > > > > > > $ ./ctrlbreak.exe > > > > > > > ### ctrlbreak: Waiting now... > > > > > > > SIGINT=2 > > > > > > > > > > > > > > > > > > > > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1 > > > > > > > bash-2.02$ ./ctrlbreak > > > > > > > ### ctrlbreak: Waiting now... > > > > > > > SIGINT=2 > > > > > > > > > > > > > > // cmd.exe Win2k SP2 > > > > > > > ### ctrlbreak: Waiting now... > > > > > > > SIGINT=2 > > > > > > > ### ctrlbreak: Finished waiting now... > > > > > > > > > > > > > > > > > > > > > You can see that under the cmd shell the text "Finished waiting > now..." > > > > > is > > > > > > > printed which does not come out under the bash. The app is not > linked > > > > > > > against any cygwin library. It is a plain VC++ console > application. But > > > > > > when > > > > > > > I compile with gcc from the cygwin package I have the same > result. > > > > > > > Any hint would be greatly appreciated... > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > PS: I just downloaded the latest stable version 1.3.6 today... > > > -- Gregory W. Bond AT&T Labs - Research 180 Park Avenue, Rm. D273, Bldg. 103 P.O. Box 971, Florham Park, NJ, 07932-0971, USA tel: (973) 360 7216 fax: (973) 360 8187 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/