Re: GDB (not) handling SIGINT...?

[Pedro Alves <palves at redhat dot com>]

On 11/15/2018 03:51 PM, Paul Smith wrote:
> On Thu, 2018-11-15 at 13:55 +0000, Pedro Alves wrote:
>> #2 - If you attach to a process instead of running it from GDB, then ctrl-c
>>      reaches gdb first, and then GDB sends/forwards a SIGINT to the child process.
> 
> To me this seems to be the problem.  I've explicitly said I don't want
> the signal passed to the process under debug (not a child process in
> this situation right?)--in fact that's the default setting for SIGINT
> --but yet GDB is still passing the signal along.
> 
> Isn't that incorrect behavior?

Not normally, because GDB is not really "passing" the signal.  It's
kill-ing the process with SIGINT, just like if you send a SIGINT
from a separate terminal with "kill -INT $PID".  Normally, ptrace (and
thus gdb) intercepts the just-sent SIGINT _before_ the inferior ever
sees it, and prints the "Program received signal SIGINT" message.
At which point, the handle SIGINT pass/nopass settings come into effect,
if the inferior is resumed again.

The problem is that sigwait makes it so that ptrace does _not_
intercept that SIGINT.  It's sigwait that is special.  So that
SIGINT that GDB sends thinking that ptrace will intercept it,
is not intercepted, but does straight to the inferior.

If your program was instead stopped in sleep(), then with
"handle SIGINT nopass", the SIGINT would _not_ ever be passed to
the inferior.

Of course this means that to handle this, GDB's mechanism to
interrupt the inferior needs to be different.  Evidently kill'ing the
inferior with SIGINT thinking that ptrace will intercept the SIGINT
doesn't work in all cases.

> 
> Is it there just for parity between the behavior of attaching to an
> existing process versus running the process under GDB?  

Yeah, I think so.

> I'd prefer it
> work one way and not the other, rather than not work either way :).

Yeah.  :-)

> 
> In my environment I'm _always_ attaching because our processes need to
> be started through a separate service, or they don't have proper
> security tokens to join the system.  So it would work OK for me if just
> the attached version behaved as expected.  I get that others may have
> different needs.

With current GDB, you can work around this by attaching in non-stop mode
("set non-stop on"), and then using "continue&" to continue in the
background, and the "interrupt" command to interrupt.  In that mode,
that command stops processes with SIGSTOP, not SIGINT.  It's a lot
more convenient with an IDE driving GDB than on the CLI, though.

If you're OK with hacking GDB, s/SIGINT/SIGSTOP/g in child_pass_ctrlc
should work reasonably OK, even though not perfect.

Thanks,
Pedro Alves