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
