From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24396 invoked by alias); 7 Jan 2002 09:58:20 -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 24365 invoked from network); 7 Jan 2002 09:58:20 -0000 Received: from unknown (HELO mail.brokat.de) (212.9.175.131) by sources.redhat.com with SMTP; 7 Jan 2002 09:58:20 -0000 Received: by mail.brokat.de (Smail3.2.0.111/mail.brokat.de) via LF.net GmbH Internet Services via remoteip 172.17.24.197 via remotehost pcmrumpf with smtp for sourceware.cygnus.com id m16NWZv-001mmeC; Mon, 7 Jan 2002 11:00:27 +0100 (CET) Message-ID: <011401c19762$04185fe0$c51811ac@brokat.de> From: "Michael Rumpf" To: Cc: "Robert Collins" References: <00f201c18922$2783b180$c51811ac@brokat.de><003c01c18936$55ca5fd0$c51811ac@brokat.de><05cb01c18a07$85d72c40$c51811ac@brokat.de><02f701c19516$5212afa0$c51811ac@brokat.de><20020104170443.GD30445@redhat.com> <00dc01c19758$02b30f10$c51811ac@brokat.de> <1010394535.566.10.camel@lifelesswks> Subject: Re: bash/cmd CTRL-C problem... Date: Mon, 07 Jan 2002 01:58:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2002-01/txt/msg00265.txt.bz2 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/