Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Date: Thu, 30 Sep 1999 00:04:37 -0400 From: Chris Faylor To: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: Exit status for fatal signals is broken Message-ID: <19990930000437.A8684@cygnus.com> Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com Mail-Followup-To: cygwin-developers AT sourceware DOT cygnus DOT com References: <19990929235335 DOT A8452 AT cygnus DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990929235335.A8452@cygnus.com>; from cgf on Wed, Sep 29, 1999 at 11:53:35PM -0400 (I've redirected this to cygwin-developers) The fix was simple. I removed the mask. Thanks for pointing this out. -chris On Wed, Sep 29, 1999 at 07:41:39PM -0400, Patrick J. LoPresti wrote: >(This is with the 19990926 snapshot, although similar behavior happens >in B20.1) > >If I run "sleep 100 && echo hi" and hit ctrl-c before the sleep >terminates, the echo runs anyway. In fact, I do not think a proper >exit status is ever returned when a process dies due to receiving a >signal. Analysis follows. > >The last line of drct0.cc:do_exit() is the following: > > ExitProcess (n & ~EXIT_SIGNAL); > >That is, the process exit status *never* has the EXIT_SIGNAL bit set. > >In sigproc.cc:stopped_or_terminated(), we have this bit of code: > > DWORD status; > if (!GetExitCodeProcess (child->hProcess, &status)) > status = 0xffff; > if (status & EXIT_SIGNAL) > w->status = (status >> 8) & 0xff; /* exited due to signal */ > else > w->status = (status & 0xff) << 8; /* exited via "exit ()" */ > >Now, since the EXIT_SIGNAL bit is never set, `status' is going to be >truncated to 8 bits by the else clause. This will give a zero exit >status when the process exited because of a signal. Well, that is the >behavior I am observing, anyway. > >Since I do not really understand what this code is trying to do (why >all the funny shifts when filling in w->status?), I am not sure how to >fix this. I suspect (hope?) the fix is pretty simple, though.