Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11556
| From | Stephane Chazelas <stephane.chazelas@gmail.com> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: SIGINT handling |
| Date | 2015-09-24 11:53 +0100 |
| Message-ID | <mailman.1711.1443092023.19560.bug-bash@gnu.org> (permalink) |
| References | (2 earlier) <20150919213101.GA4393@chaz.gmail.com> <56035164.30105@case.edu> <20150924060122.GA4338@chaz.gmail.com> <20150924062044.GA5756@chaz.gmail.com> <5603B5F8.3080800@draigBrady.com> |
2015-09-24 09:36:08 +0100, Pádraig Brady:
[...]
> > (gdb) handle SIGINT nostop pass
[...]
>
> In case it's relevant, I'm not entirely sure of gdb's signal handling:
> https://sourceware.org/bugzilla/show_bug.cgi?id=18364
Yes, I wondered about that.
I'd expect the "handle SIGINT nostop pass", to take gdb out of
the loop, but I've not verified it and I suspect ptracing could
have side effects.
It's easy to corroborate with printfs though here which I just
did:
$ ./bash -c './a; echo x'
^Cwait_sigint_received=1 pid=-1
wait_sigint_received=1 pid=956
x
$ ./bash -c './a; echo x'
^Cwait_sigint_received=1 pid=958
$ diff -pu jobs.c\~ jobs.c
--- jobs.c~ 2015-09-20 20:03:14.692119372 +0100
+++ jobs.c 2015-09-24 11:49:03.963122465 +0100
@@ -3262,6 +3262,7 @@ itrace("waitchld: waitpid returns %d blo
require the child to actually die due to SIGINT to act on the
SIGINT we received; otherwise we assume the child handled it and
let it go. */
+ fprintf(stderr, "wait_sigint_received=%d pid=%d\n", wait_sigint_received, pid);
if (pid < 0 && errno == EINTR && wait_sigint_received)
child_caught_sigint = 1;
--
Stephane
Back to gnu.bash.bug | Previous | Next | Find similar
Re: SIGINT handling Stephane Chazelas <stephane.chazelas@gmail.com> - 2015-09-24 11:53 +0100
csiph-web