Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
From: patl AT cag DOT lcs DOT mit DOT edu (Patrick J. LoPresti)
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Exit status for fatal signals is broken
Date: 29 Sep 1999 19:41:39 -0400
Message-ID: <s5ghfkde158.fsf@egghead.curl.com>
Lines: 34

(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.

 - Pat

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com