[Bug gdb/27319] New: multi-target: ^C goes to the wrong place

[Bug gdb/27319] New: multi-target: ^C goes to the wrong place

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=27319

            Bug ID: 27319
           Summary: multi-target: ^C goes to the wrong place
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: simark at simark dot ca
  Target Milestone: ---

With GDB in this state:

- Inferior 1 native, doing a "continue" in the background
- Inferior 2 remote, doing a "continue" in the foreground

Pressing ^C, the ^C is routed to the native target, which proceeds to
kill(SIGINT) the pid of inferior 2.  That's wrong, because inferior 2 is not
handled by that target.  Inferior 2 could be on a different machine, so the
native target could end up killing an unrelated process on the host machine,
that happens to have the same pid as inferior 2.

When inferior 2 is on the same machine as GDB, things work because the
kill(SIGINT) ends up having the desired effect.

Repro:

$ ./gdb -nx --data-directory=data-directory -q /bin/sleep -ex "set confirm off"
-ex "maint set target-non-stop on" -ex "r 9999 &" -ex "add-inferior -exec
/bin/sleep -no-connection" -ex "inferior 2" -ex "tar ext :1234"

And run gdbserver with:

$ gdbserver --once :1234 /bin/sleep 11111

Then, do "continue" in GDB and try interrupting with ^C.

To observe the wrong behavior, break on default_quit_handler in GDB and step
from there.

And to better show the problem, run with inferior 2 on a separate machine, just
use the appropriate IP address in the "tar ext :1234" command.  You'll find
that the ^C does nothing, because it ends up killing(SIGINT) a process on the
wrong machine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/27319] multi-target: ^C goes to the wrong place

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=27319

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
I think that this change would be desirable, it makes child_pass_ctrlc only
consider inferiors from the native target (passed as a parameter).  With the
repro from above, it makes us hit the assert at the end of the function:

  gdb_assert_not_reached ("no inferior resumed in the fg found");

But that just exposes the fact that we asked the wrong target to ctrlc, I think
we should ask the target that owns the inferior that is in the foreground.


diff --git a/gdb/inferior.h b/gdb/inferior.h
index b8d5ff94fc56..c63a66f70713 100644
--- a/gdb/inferior.h
+++ b/gdb/inferior.h
@@ -178,7 +178,7 @@ extern void child_terminal_init (struct target_ops *self);

 extern void child_terminal_init_with_pgrp (int pgrp);

-extern void child_pass_ctrlc (struct target_ops *self);
+extern void child_pass_ctrlc (process_stratum_target *self);

 extern void child_interrupt (struct target_ops *self);

diff --git a/gdb/inflow.c b/gdb/inflow.c
index b3d90aa87cab..b317005db8ae 100644
--- a/gdb/inflow.c
+++ b/gdb/inflow.c
@@ -553,7 +553,7 @@ child_interrupt (struct target_ops *self)
    target_pass_ctrlc for child/native targets.  */

 void
-child_pass_ctrlc (struct target_ops *self)
+child_pass_ctrlc (process_stratum_target *self)
 {
   gdb_assert (!target_terminal::is_ours ());

@@ -580,7 +580,7 @@ child_pass_ctrlc (struct target_ops *self)

   /* Otherwise, pass the Ctrl-C to the first inferior that was resumed
      in the foreground.  */
-  for (inferior *inf : all_inferiors ())
+  for (inferior *inf : all_inferiors (self))
     {
       if (inf->terminal_state != target_terminal_state::is_ours)
        {

-- 
You are receiving this mail because:
You are on the CC list for the bug.