Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11556

Re: SIGINT handling

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>

Show all headers | View raw


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


Thread

Re: SIGINT handling Stephane Chazelas <stephane.chazelas@gmail.com> - 2015-09-24 11:53 +0100

csiph-web