[Bug gdb/27055] New: Attaching to a process in non-stop mode doesn't work

[Bug gdb/27055] New: Attaching to a process in non-stop mode doesn't work

[simark at simark dot ca]

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

            Bug ID: 27055
           Summary: Attaching to a process in non-stop mode doesn't work
           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: ---

The program a.out is a simple infinite loop:

#include <unistd.h>

int main() {
    for (;;) {
        sleep (5);
    }
}


Attaching to the process in non-stop mode gives this:

$ ./gdb -q -nx --data-directory=data-directory -ex "set non-stop on"
(gdb) attach 2896612
Attaching to process 2896612
No unwaited-for children left.
(gdb) i th
  Id   Target Id               Frame 
* 1    process 2896612 "a.out" 0xc856e334 in ?? ()
(gdb) bt
#0  0xc856e334 in ?? ()

The state seems a bit broken.  However, continuing and doing ^C makes GDB fall
back on its feet:

(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0xc856e334 in ?? ()
Reading symbols from /home/smarchi/build/binutils-gdb-all-targets/gdb/a.out...
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...

Program received signal SIGINT, Interrupt.
0x00007f01c856e334 in __GI___clock_nanosleep (clock_id=<optimized out>,
clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffc5dbb6f70,
rem=rem@entry=0x7ffc5dbb6f70) at
../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78      ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or
directory.
(gdb) bt
#0  0x00007f01c856e334 in __GI___clock_nanosleep (clock_id=<optimized out>,
clock_id@entry=0, 
    flags=flags@entry=0, req=req@entry=0x7ffc5dbb6f70,
rem=rem@entry=0x7ffc5dbb6f70)
    at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
#1  0x00007f01c8574047 in __GI___nanosleep (
    requested_time=requested_time@entry=0x7ffc5dbb6f70, 
    remaining=remaining@entry=0x7ffc5dbb6f70) at nanosleep.c:27
#2  0x00007f01c8573f7e in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#3  0x0000563bb85cb15b in main () at test.c:7


A second test is making GDB attach to a process while another one is running:

$ ./gdb -q -nx --data-directory=data-directory a.out -ex "set non-stop on" -ex
"r&" -ex "add-inferior" -ex "inferior 2"
Reading symbols from a.out...
Starting program: /home/smarchi/build/binutils-gdb-all-targets/gdb/a.out 
[New inferior 2]
Added inferior 2 on connection 1 (native)
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) attach 2896985
Attaching to process 2896985
^C^C^C^C

The attach doesn't go through and GDB doesn't respond to inputs.

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

[Bug gdb/27055] Attaching to a process in non-stop mode doesn't work

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

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

[Bug gdb/27055] Attaching to a process in non-stop mode doesn't work

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2ab76a181f3db93f051aaae66d65ff2733884d96

commit 2ab76a181f3db93f051aaae66d65ff2733884d96
Author: Pedro Alves <pedro@palves.net>
Date:   Wed Dec 23 00:34:54 2020 +0000

    Fix attaching in non-stop mode (PR gdb/27055)

    Attaching in non-stop mode currently misbehaves, like so:

     (gdb) attach 1244450
     Attaching to process 1244450
     [New LWP 1244453]
     [New LWP 1244454]
     [New LWP 1244455]
     [New LWP 1244456]
     [New LWP 1244457]
     [New LWP 1244458]
     [New LWP 1244459]
     [New LWP 1244461]
     [New LWP 1244462]
     [New LWP 1244463]
     No unwaited-for children left.

    At this point, GDB's stopped/running thread state is out of sync with
    the inferior:

    (gdb) info threads
      Id   Target Id                     Frame
    * 1    LWP 1244450 "attach-non-stop" 0xf1b443bf in ?? ()
      2    LWP 1244453 "attach-non-stop" (running)
      3    LWP 1244454 "attach-non-stop" (running)
      4    LWP 1244455 "attach-non-stop" (running)
      5    LWP 1244456 "attach-non-stop" (running)
      6    LWP 1244457 "attach-non-stop" (running)
      7    LWP 1244458 "attach-non-stop" (running)
      8    LWP 1244459 "attach-non-stop" (running)
      9    LWP 1244461 "attach-non-stop" (running)
      10   LWP 1244462 "attach-non-stop" (running)
      11   LWP 1244463 "attach-non-stop" (running)
    (gdb)
    (gdb) interrupt -a
    (gdb)
    *nothing*

    The problem is that attaching installs an inferior continuation,
    called when the target reports the initial attach stop, here, in
    inf-loop.c:inferior_event_handler:

          /* Do all continuations associated with the whole inferior (not
             a particular thread).  */
          if (inferior_ptid != null_ptid)
            do_all_inferior_continuations (0);

    However, currently in non-stop mode, inferior_ptid is still null_ptid
    when we get here.

    If you try to do "set debug infrun 1" to debug the problem, however,
    then the attach completes correctly, with GDB reporting a stop for
    each thread.

    The bug is that we're missing a switch_to_thread/context_switch call
    when handling the initial stop, here:

      if (stop_soon == STOP_QUIETLY_NO_SIGSTOP
          && (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_STOP
              || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP
              || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_0))
        {
          stop_print_frame = true;
          stop_waiting (ecs);
          ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
          return;
        }

    Note how the STOP_QUIETLY / STOP_QUIETLY_REMOTE case above that does
    call context_switch.

    And the reason "set debug infrun 1" "fixes" it, is that the debug path
    has a switch_to_thread call.

    This patch fixes it by moving the main context_switch call earlier.
    It also removes the:

       if (ecs->ptid != inferior_ptid)

    check at the same time because:

     #1 - that is half of what context_switch already does

     #2 - deprecated_context_hook is only used in Insight, and all it does
          is set an int.  It won't care if we call it when the current
          thread hasn't actually changed.

    A testcase exercising this will be added in a following patch.

    gdb/ChangeLog:

            PR gdb/27055
            * infrun.c (handle_signal_stop): Move main context_switch call
            earlier, before STOP_QUIETLY_NO_SIGSTOP.

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

[Bug gdb/27055] Attaching to a process in non-stop mode doesn't work

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
Fixed.

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