[Bug remote/33569] New: Not correctly stopping on breakpoint with multiple inferiors

[andreas.ragnerstam at intel dot com]

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

            Bug ID: 33569
           Summary: Not correctly stopping on breakpoint with multiple
                    inferiors
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: remote
          Assignee: unassigned at sourceware dot org
          Reporter: andreas.ragnerstam at intel dot com
  Target Milestone: ---

Created attachment 16433
  --> https://sourceware.org/bugzilla/attachment.cgi?id=16433&action=edit
Files to help reproduce the issue

I have run into an issue where extended-remote with multiple processes will end
up in a state where it is not considered stopped even though it should be, and
will not return to gdb prompt unless ctrl-c is pressed multiple times.

My case is the following:
I attach with extended-remote to a gdb server (with multi enabled) that is
already attached to one process. This will end up attached to inferior 1 after
connection.
I place a breakpoint that is present and will hit for the process in inferior
1:
b foo

Then I add an additional inferior and attach that inferior to a process with
pid X:
add-inferior
inferior 2
attach X
set schedule-multiple on

The I resume using "c", while inferior 2 is selected.

When the breakpoint hits the gdb client will end up in a state where it does
not return to prompt. Debugging shows that gdb is running "poll".
With "set debug remote 1" I see that a breakpoint has hit and a stop reply has
been sent:

Packet received:
T05swbreak:;06:20deffffff7f0000;07:80dbffffff7f0000;10:c26efdf7ff7f0000;thread:p3a05.3a05;core:8;

But I never reach gdb prompt.

My example can be reproduced with the following steps using the attached
reproducer-files.tar file:
> tar x reproducer-files.tar
> gcc -O0 -g -o foo foo.c
> gcc -O0 -g -o bar bar.c
> ./bar &
> gdbserver --multi :9124 foo &
> gdb -x setup.gdb
(gdb) attach <pid of bar>
(gdb) c


Debugging a bit why this happens it's because inf->control.stop_soon gets set
to STOP_QUIETLY_REMOTE in infrun.c:start_remote(from_tty). This is updated
*after* the initial stop_reply from "?" is handled, which sets
stop_soon=NO_STOP_QUIETLY.
Then when infrun.c:handle_signal_stop is run as part of hitting the breakpoint
that function exits with "quietly stopped" reason.

If I instead run "c" with inferior 1 selected then there is no longer a problem
as resuming will update stop_soon state for current_inferior, which is the 1.
Also just running "stepi" on inferior 1 then "c" on inferior 2 will work as the
stop_soon state of inferior 1 will never go back to STOP_QUIETLY_REMOTE.

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