Mail Archives: cygwin/2000/10/02/11:42:25
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
- Raw text -