This is the mail archive of the
mailing list for the Cygwin project.
CGF: please review my logic Re: bash/cmd CTRL-C problem...
I didn't realise that signal() is implemented in the standard VC++
Can you tell me any details of the signal implementation you are using
If you wished to follow clean room r/e for this, I can implement the
signal sending side to match up with what your library expects.
Also, according to
SIGINT is not supported for win32 programs. I quote:
"Note SIGINT is not supported for any Win32 application including
Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32
operating systems generate a new thread to specifically handle that
interrupt. This can cause a single-thread application such as UNIX, to
become multithreaded, resulting in unexpected behavior. "
As for why you see the current behaviour, I'm a little mystified.
Firstly, here's a snippet of the output of a strace of kill -2
2149 2816627 [main] kill 920 _kill: kill (3656, 2)
1542 2818169 [main] kill 920 sig_send: pid 3656, signal 2, its_me 0
1387 2819556 [main] kill 920 getsem: pid 3656, ppid 3648, wait 1000,
1776 2821332 [main] kill 920 sig_send: Not waiting for sigcomplete.
its_me 0 signal 2
3817 2825149 [main] kill 920 sig_send: returning 0 from sending signal
2529 2827678 [main] kill 920 kill_worker: 0 = kill_worker (3656, 2)
The getsem line is whats interesting: This is retrieving the semaphore
used to syncronise the signalling across process's.
It succeeds! (I'm running a slightly modified cygwin here, which as the
patch at the end of this email shows (in combination with the source :})
should always indicate if there is an error).
It shouldn't succeed - Sysinternals process explorer shows signals.exe
as having no semaphores at all, let alone a named semaphore with the
further investigation finds that bash has got the semaphore for the
process pid that signals has, and that Ctrl-C is actually being recieved
by bash, which is running as a sub-process.
Doing a ps in another bash shell will show /path/to/signals against a
PID that if you look up in the windows PID list is actually bash. Cygwin
is pretending that signals.exe is a cygwin app via the use of a dummy
bash process, that has called exec(), but is kept around to recieve
So here's my best guess as to whats happening:
When you hit CTRL-C, it propogates to
signals.exe (handled as you expect)
bash.exe (still attached to the console and gets handled via default
signal handler - exit and terminate all subprocess's - which kills
If you have time, and wanted to test this, you could make a three level
test program. I would appreciate if you could do this as it be an
independent confirmation of the analysis.
outer level - recieved CTRL-C, prints that it's got it, and
quits(without terminateding signals.exe).
middle level - signals.exe
inner level - myclass.exe.
I'd expect that you'd see the outer level get killed in the same fashion
as you currently see signals.exe die. the middle level would run and
kill myclass correctly.
As for how to fix this, I won't speculate until we confirm this
analysis. I've flagged this email for Chris's attention (I've not done
much on the signal handling code) and if he agrees with my analysis I
will look at ways to address this somewhat...inconvenient behaviour :}
RCS file: /cvs/src/src/winsup/cygwin/sigproc.cc,v
retrieving revision 184.108.40.206
diff -u -p -r220.127.116.11 sigproc.cc
--- sigproc.cc 2002/01/04 03:56:10 18.104.22.168
+++ sigproc.cc 2002/01/07 12:54:59
@@ -953,7 +953,6 @@ getsem (_pinfo *p, const char *str, int
- return NULL;
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html