Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Mon, 2 Oct 2000 11:40:24 -0400
To: cygwin AT sources DOT redhat DOT com
Cc: cabbey AT bresnanlink DOT net
Subject: Re: signals?
Message-ID: <20001002114023.H13304@cygnus.com>
Reply-To: cygwin AT sources DOT redhat DOT com
Mail-Followup-To: cygwin AT sources DOT redhat DOT com, cabbey AT bresnanlink DOT net
References: <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001001212519 DOT 00c09bb0 AT pop>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <4.3.2.7.0.20001001212519.00c09bb0@pop>; from cabbey@bresnanlink.net on Sun, Oct 01, 2000 at 10:41:28PM -0500

On Sun, Oct 01, 2000 at 10:41:28PM -0500, Chris Abbey wrote:
>Does anyone out there really understand signal handling in cygwin?

Yes.  Intimately.

>Here's the situation... I have a win32 application that has a signal
>handler registered for SIGQUIT. Running the application from cmd.exe
>(I'm on NT4) and then using ctrl-break to send a SIGQUIT (or selecting
>it from the task manager and clicking kill job, then cancel on the
>dialog that says it hasn't exited yet) will result in the signal handler
>taking over and dumping a bunch of information about the process' status
>to stdout then the application's normal function resumes. This all works
>fine, and you can do this hundreds of thousands of times without any
>problem. The same application under Linux or AIX behaves the same way.
>(except that it's ctrl-\ or kill -QUIT <pid> to send the signal)

SIGQUIT != CTRL-BREAK.

>Enter cygwin.
>
>ctrl-\ does nothing (ok, that's a shell-ism so no big deal...)
>
>ctrl-break signals the child process and it begins to work, but
>   almost immediately the process is terminated. close, but not
>   quite there.... :(
>
>kill -QUIT kills the process with a message "Quit (core dumped)"
>   and produces a "stackdump" file.
>
>I've tried various other tricks for launching the process, including
>nohup, cmd /c, start... none come as close as ctrl-break, where our
>signal handler is at least called. it also doesn't seem to matter
>what shell is being used, bash and sh both behave the same.

SIGQUIT != CTRL-BREAK.

and, this

#include <stdio.h>
#include <sys/signal.h>

int
ouch (int sig)
{
  printf ("sig %d\n", sig);
  return;
}


int
main (int argc, char **argv)
{
  signal (SIGQUIT, ouch);
  sleep(20);
  puts ("exiting");
}

seems to work fine for me.

>I've read the programmer's guide entry about signals, which includes
>the following:
>
>"When a process notices it has a signal, it scans its signal bitmask
>and handles the signal in the appropriate fashion."
>
>anyone know how I can manipulate this mask? or the "appropriate"
>handling choices?

Same as UNIX: sigprocmask, etc.

>I really suspect that the problem is that the child process registers
>for signals via the win32 API, not the cygwin API. Is there any way I
>can work around this? Any suggestions welcomed, as I said this is really
>getting annoying.

I suspect that your assumptions that SIGQUIT == CTRL-BREAK are your major
problem.  I don't see any hint of a "SIGQUIT" in the MSDEV includes and
a search for SIGQUIT at the MSDDN online search does not yield anything
which indicates that it should be exercised when you press CTRL-BREAK.

Cygwin equates CTRL-BREAK with CTRL-C.  Both send a SIGINT to the process.

cgf

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