[Bug server/31554] New: gdbserver --once --multi mishandles run & attach failures

[Bug server/31554] New: gdbserver --once --multi mishandles run & attach failures

[pedro at palves dot net]

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

            Bug ID: 31554
           Summary: gdbserver --once --multi mishandles run & attach
                    failures
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: server
          Assignee: unassigned at sourceware dot org
          Reporter: pedro at palves dot net
  Target Milestone: ---

"gdbserver --once --multi" mishandles run or attach failures.  GDBserver
exits/disconnects on run/attach failure, but it should not.  From --help:

  --multi               Start server without a specific program, and
                        only quit when explicitly commanded.
  --once                Exit after the first connection has closed.


E.g., for "run":

    On GDB side:

     ...
     (gdb) tar extended-remote :9999
     ...
     Remote debugging using :9999
     (gdb) r
     Starting program:
     Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote
target failed
     (gdb)

    On GDBserver side:

     $ gdbserver --once --multi :9999
     Remote debugging from host 127.0.0.1, port 34344
     bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission
denied
     bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot
execute: Permission denied
     gdbserver: During startup program exited with code 126.
     $   # gdbserver exited

This gdbserver exit is wrong, as we've connected with extended-remote/--multi.

Here's an example for "attach":

    On GDB side:

     ...
     (gdb) tar extended-remote :9999
     ...
     Remote debugging using :19999
     (gdb) attach 1
     Attaching to process 1
     Attaching to process 1 failed
     (gdb) 

    On GDBserver side:

     $ gdbserver --once --multi :9999
     Listening on port 9999
     Remote debugging from host 127.0.0.1, port 37464
     gdbserver: Cannot attach to process 1: Operation not permitted (1)
     $   # gdbserver exited

This gdbserver exit is also wrong, as we've connected with
extended-remote/--multi.

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

[Bug server/31554] gdbserver --once --multi mishandles run & attach failures

[pedro at palves dot net]

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

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |pedro at palves dot net
             Status|NEW                         |ASSIGNED

--- Comment #1 from Pedro Alves <pedro at palves dot net> ---
Got patch for "run", and noticed "attach" also has the same problem while
writing an unrelated testcase...

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

[Bug server/31554] gdbserver --once --multi mishandles run & attach failures

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from Sourceware Commits <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=ec48903170926f3827144525b50ddd3c6ae3fbf0

commit ec48903170926f3827144525b50ddd3c6ae3fbf0
Author: Pedro Alves <pedro@palves.net>
Date:   Mon Mar 25 15:17:02 2024 +0000

    New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153)

    Add a new testcase for exercising attaching to a process after its
    main thread has exited.

    This is not possible on Linux, the kernel does not allow attaching to
    a zombie task, so the test is kfailed there.  It is possible however
    on Windows at least, and was the scenario addressed by the Windows
    backend fix in
    https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html,
    nowadays PR threads/8153, back in 2003.

    Passes cleanly on Cygwin.
    KFAILed on GNU/Linux native and gdbserver.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555
    Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b

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

[Bug server/31554] gdbserver --once --multi mishandles run & attach failures

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from Sourceware Commits <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=f1fc8dc2dccb4a224cdd1c3973c7a09a752aa95b

commit f1fc8dc2dccb4a224cdd1c3973c7a09a752aa95b
Author: Pedro Alves <pedro@palves.net>
Date:   Wed Apr 17 19:26:32 2024 +0100

    Fix "attach" failure handling with GDBserver

    This fixes the same issue as the previous patch, but for "attach"
    instead of "run".

    If attaching to a process with "attach" (vAttach packet) fails,
    GDBserver throws an error that escapes all the way to the top level.
    When an error escapes all the way like that, GDBserver interprets it
    as a disconnection, and either goes back to waiting for a new GDB
    connection, or exits, if --once was specified.

    Here's an example:

    On the GDB side:

     ...
     (gdb) tar extended-remote :9999
     ...
     Remote debugging using :9999
     (gdb) attach 1
     Attaching to process 1
     Attaching to process 1 failed
     (gdb)

    On the GDBserver side:

     $ gdbserver --once --multi :9999
     Listening on port 9999
     Remote debugging from host 127.0.0.1, port 37464
     gdbserver: Cannot attach to process 1: Operation not permitted (1)
     $   # gdbserver exited

    This is wrong, as we've connected with extended-remote/--multi.
    GDBserver should just report an error to vAttach, and continue
    connected to GDB, waiting for other commands.

    This commit fixes GDBserver by catching the error locally in
    handle_v_attach.

    Note we now let pid == 0 pass down to attach_inferior.  That is so we
    get a useful textual error message to report to GDB.

    This fixes a couple KFAILs in gdb.base/attach.exp.  Still, I thought
    it would be useful to add a new testcase specifically for this
    scenario, in case gdb.base/attach.exp is ever split and stops trying
    to attach again after a failed attach, with the same GDB session.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554

    Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393
    Approved-By: Tom Tromey <tom@tromey.com>

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

[Bug server/31554] gdbserver --once --multi mishandles run & attach failures

[pedro at palves dot net]

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

Pedro Alves <pedro at palves dot net> changed:

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

--- Comment #4 from Pedro Alves <pedro at palves dot net> ---
All fixed.

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