Re: SIGINT handling

[Stephane Chazelas]

2015-09-23 21:27:00 -0400, Chet Ramey:
> On 9/19/15 5:31 PM, Stephane Chazelas wrote:
> 
> > In case it was caused by some Debian patch, I recompiled the
> > code of 4.3.42 from gnu.org and the one from the devel branch on
> > the git repository (commit bash-20150911 snapshot) and still:
> > 
> > $ ./bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
> > ^Chi
> > $ ./bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
> > ^Chi
> > $ ./bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
> > ^C
> > $ ./bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
> > ^Chi
> > 
> > Sometimes (and the frequency of occurrences is erratic,
> > generally roughly 80% of "hi"s but at times, I don't see a "hi"
> > in a while), the "hi" doesn't show up. Note that I press ^C well
> > after sleep has started.
> 
> It would be nice to see a system call trace for this so we can check
> what's going on with the timing.

I don't have them logged but I did several tests in gdb
with "handle SIGINT nostop pass" and as I said before, 
Upon the test that sets child_caught_sigint, waitpid() has not
returned with EINTR and wait_sigint_received has been set.

If I break on the SIGINT handler, I see the call trace at the
return of the "syscall".

I can try and get you a call trace later today.

> 
> Can you reproduce this on anything other than Debian?  I'm wondering
> whether it's a Linux-4 kernel phenomenon.  Plus I don't have any
> Debian machines laying around.


It's hard to reproduce on an idle system. It's relatively easy
to reproduce on a busy one and if the "cmd" exits shortly after
receiving its SIGINT. I can reproduce on a Ubuntu 14.04 with an
older kernel (3.13). I can't reproduce on FreeBSD (in a VM
though).


cmd ==
#include <unistd.h>
main() {signal(2,_exit);pause();}

$ tar zcf - / >& /dev/null &
[1] 4417
$ tar zcf - / >& /dev/null &
[2] 4419
$ tar zcf - / >& /dev/null &
[3] 4421
$ bash -c './a.out; echo x'
^Cx
$ bash -c './a.out; echo x'
^C

Works on second attempt.

-- 
Stephane