Re: SIGINT handling

[Stephane Chazelas]

2015-09-24 07:01:23 +0100, 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.
[...]

(gdb) handle SIGINT nostop pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y
Signal        Stop      Print   Pass to program Description
SIGINT        No        Yes     Yes             Interrupt
(gdb) break wait_sigint_handler
Breakpoint 1 at 0x443a70: file jobs.c, line 2241.
(gdb) run
Starting program: bash-4.3/bash -c ./a\;\ echo\ x
^C
Program received signal SIGINT, Interrupt.

Breakpoint 1, wait_sigint_handler (sig=2) at jobs.c:2241
2241    {
(gdb) bt
#0  wait_sigint_handler (sig=2) at jobs.c:2241
#1  <signal handler called>
#2  0x00007ffff76bc31c in __libc_waitpid (pid=pid@entry=-1, 
stat_loc=stat_loc@entry=0x7fffffffdbc8, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:31
#3  0x0000000000445f3d in waitchld (block=block@entry=1, wpid=5337) at 
jobs.c:3224
#4  0x000000000044733b in wait_for (pid=5337) at jobs.c:2485
#5  0x0000000000437992 in execute_command_internal 
(command=command@entry=0x70bb88, asynchronous=asynchronous@entry=0, 
pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1,
    fds_to_close=fds_to_close@entry=0x70bde8) at execute_cmd.c:829
#6  0x0000000000437b0e in execute_command (command=0x70bb88) at 
execute_cmd.c:390
#7  0x0000000000435f23 in execute_connection (fds_to_close=0x70bdc8, 
pipe_out=-1, pipe_in=-1, asynchronous=0, command=0x70bd88) at execute_cmd.c:2494
#8  execute_command_internal (command=0x70bd88, 
asynchronous=asynchronous@entry=0, pipe_in=pipe_in@entry=-1, 
pipe_out=pipe_out@entry=-1, fds_to_close=fds_to_close@entry=0x70bdc8)
    at execute_cmd.c:945
#9  0x000000000047955b in parse_and_execute (string=<optimized out>, 
from_file=from_file@entry=0x4b5f96 "-c", flags=flags@entry=4) at 
evalstring.c:387
#10 0x00000000004205d7 in run_one_command (command=<optimized out>) at 
shell.c:1348
#11 0x000000000041f524 in main (argc=3, argv=0x7fffffffe258, 
env=0x7fffffffe278) at shell.c:695
(gdb) frame 2
#2  0x00007ffff76bc31c in __libc_waitpid (pid=pid@entry=-1, 
stat_loc=stat_loc@entry=0x7fffffffdbc8, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:31
31      ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
(gdb) disassemble
Dump of assembler code for function __libc_waitpid:
   0x00007ffff76bc300 <+0>:     mov    0x2f14cd(%rip),%r9d        # 
0x7ffff79ad7d4 <__libc_multiple_threads>
   0x00007ffff76bc307 <+7>:     test   %r9d,%r9d
   0x00007ffff76bc30a <+10>:    jne    0x7ffff76bc336 <__libc_waitpid+54>
   0x00007ffff76bc30c <+12>:    xor    %r10d,%r10d
   0x00007ffff76bc30f <+15>:    movslq %edx,%rdx
   0x00007ffff76bc312 <+18>:    movslq %edi,%rdi
   0x00007ffff76bc315 <+21>:    mov    $0x3d,%eax
   0x00007ffff76bc31a <+26>:    syscall
=> 0x00007ffff76bc31c <+28>:    cmp    $0xfffffffffffff000,%rax
   0x00007ffff76bc322 <+34>:    ja     0x7ffff76bc325 <__libc_waitpid+37>
   0x00007ffff76bc324 <+36>:    retq
   0x00007ffff76bc325 <+37>:    mov    0x2ebb3c(%rip),%rdx        # 
0x7ffff79a7e68
   0x00007ffff76bc32c <+44>:    neg    %eax
   0x00007ffff76bc32e <+46>:    mov    %eax,%fs:(%rdx)
   0x00007ffff76bc331 <+49>:    or     $0xffffffffffffffff,%rax
(gdb) fin
Run till exit from #2  0x00007ffff76bc31c in __libc_waitpid (pid=pid@entry=-1, 
stat_loc=stat_loc@entry=0x7fffffffdbc8, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:31
0x0000000000445f3d in waitchld (block=block@entry=1, wpid=5481) at jobs.c:3224
3224          pid = WAITPID (-1, &status, waitpid_flags);
Value returned is $5 = 5337
(gdb) p wait_sigint_received
$6 = 1

In the other (working) cases, the difference is that waitpid()
returs -1 EINTR instead.

Note that Bart on the zsh mailing list had noted something
similar already in 2009.

-- 
Stephane