[Bug server/15746] New: "monitor exit", then "quit" leaves gdb still running

[Bug server/15746] New: "monitor exit", then "quit" leaves gdb still running

[dje at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15746

            Bug ID: 15746
           Summary: "monitor exit", then "quit" leaves gdb still running
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: server
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

bash1$ gdbserver --multi :1234 hello

bash2$ gdb hello
(gdb) b main
(gdb) c
(gdb) monitor exit
(gdb) quit
A debugging session is active.

        Inferior 1 [process 11749] will be killed.

Quit anyway? (y or n) y
Remote connection closed
(gdb) pwd
Working directory /tmp.
(gdb) q
bash2$

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

[Bug server/15746] "monitor exit", then "quit" leaves gdb still running

[msaleem at codesourcery dot com]

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

Mohsan Saleem <msaleem at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msaleem at codesourcery dot com
           Assignee|unassigned at sourceware dot org   |msaleem at codesourcery dot com

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

[Bug server/15746] "monitor exit", then "quit" leaves gdb still running

[msaleem at codesourcery dot com]

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

--- Comment #1 from Mohsan Saleem <msaleem at codesourcery dot com> ---
I am unable to create this create this bug. Kindly can you elaborate it a
little more.

Thanks!
(In reply to dje from comment #0)
> bash1$ gdbserver --multi :1234 hello
> 
> bash2$ gdb hello
> (gdb) b main
> (gdb) c
> (gdb) monitor exit
> (gdb) quit
> A debugging session is active.
> 
>         Inferior 1 [process 11749] will be killed.
> 
> Quit anyway? (y or n) y
> Remote connection closed
> (gdb) pwd
> Working directory /tmp.
> (gdb) q
> bash2$

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

[Bug server/15746] "monitor exit", then "quit" leaves gdb still running

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #2)
> I ran into this recently as well.

And me today.  

Fairly easy to reproduce.

Terminal 1 (run this command, first compile hello world into a.out):
...
$ gdbserver --once 127.0.0.1:2345 ./a.out
...

Terminal 2 (run this command and type 'y'):
...
$ gdb -ex "target remote 127.0.0.1:2345" -ex "monitor exit" -ex quit
Remote debugging using 127.0.0.1:2345
Reading /home/vries/a.out from remote target...
  ...
0x00007ffff7dd4550 in _start () from target:/lib64/ld-linux-x86-64.so.2
A debugging session is active.

        Inferior 1 [process 13005] will be killed.

Quit anyway? (y or n) y
Remote connection closed
(gdb) 
...

It's causing timeouts when running the testsuite in fancy host/target board
combinations.

With this to make it visible:
...
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index c9533758270..07b3ddccae2 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -2046,6 +2046,9 @@ proc default_gdb_exit {} {
                exp_continue
            }
            -re "DOSEXIT code" { }
+           timeout {
+               warning "Timed out waiting for EOF"
+           }
            default { }
        }
     }
...
and host board local-remote-host-notty and target board native-gdbserver (and a
branch full of testsuite fixes, and test-case gdb.base/print-file-var.exp), I
run into:
...
Remote debugging from host ::1, port 57704^M
get_version_1: &this_version_id=0x7ffff7dd1028, this_version_id=104^M
get_version_2: &this_version_id=0x7ffff7dd1028, this_version_id=104^M
monitor exit^M
Killing process(es): 10766^M
(gdb) quit^M
A debugging session is active.^M
^M
        Inferior 1 [process 10766] will be killed.^M
^M
Quit anyway? (y or n) y^M
Remote connection closed^M
(gdb) WARNING: Timed out waiting for EOF
...

This happens as follows:
- quit_command calls query_if_trace_running
- a TARGET_CLOSE_ERROR is thrown
- it's caught in remote_target::get_trace_status, but then
  rethrow because it's TARGET_CLOSE_ERROR
- catch_command_errors catches the error, at which point quit command
  has been aborted.

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

[Bug server/15746] "monitor exit", then "quit" leaves gdb still running

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
This fixes it:
...
diff --git a/gdb/cli/cli-cmds.c b/gdb/cli/cli-cmds.c
index fe4041662ef..6a2afb69b54 100644
--- a/gdb/cli/cli-cmds.c
+++ b/gdb/cli/cli-cmds.c
@@ -488,7 +488,18 @@ quit_command (const char *args, int from_tty)
   if (!quit_confirm ())
     error (_("Not confirmed."));

-  query_if_trace_running (from_tty);
+  try
+    {
+      query_if_trace_running (from_tty);
+    }
+  catch (const gdb_exception_error &ex)
+    {
+      exception_print (gdb_stderr, ex);
+    }
+  catch (const gdb_exception_quit &)
+    {
+      /* A quit event happens while we're quitting?  Keep quitting.  */
+    }

   quit_force (args ? &exit_code : NULL, from_tty);
 }
...

Now we have:
...
Quit anyway? (y or n) y
Remote connection closed
$ 
...

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

[Bug server/15746] "monitor exit", then "quit" leaves gdb still running

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2022-November/193414.html

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

[Bug server/15746] "monitor exit", then "quit" leaves gdb still running

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |13.1
             Status|NEW                         |RESOLVED

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/git/?p=binutils-gdb.git;a=search;s=Tom+de+Vries;st=author

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

[Bug server/15746] "monitor exit", then "quit" leaves gdb still running

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit be6a2dca1505a4597fa3de71a85e7957d8d470ff
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Nov 8 18:47:24 2022 +0100

    [gdb/cli] Make quit really quit after remote connection closed

    Consider a hello world a.out, started using gdbserver:
    ...
    $ gdbserver --once 127.0.0.1:2345 ./a.out
    Process ./a.out created; pid = 15743
    Listening on port 2345
    ...
    that we can connect to using gdb:
    ...
    $ gdb -ex "target remote 127.0.0.1:2345"
    Remote debugging using 127.0.0.1:2345
    Reading /home/vries/a.out from remote target...
      ...
    0x00007ffff7dd4550 in _start () from target:/lib64/ld-linux-x86-64.so.2
    (gdb)
    ...

    After that, we can for instance quit with confirmation:
    ...
    (gdb) quit
    A debugging session is active.

            Inferior 1 [process 16691] will be killed.

    Quit anyway? (y or n) y
    $
    ...

    Or, kill with confirmation and quit:
    ...
    (gdb) kill
    Kill the program being debugged? (y or n) y
    [Inferior 1 (process 16829) killed]
    (gdb) quit
    $
    ...

    Or, monitor exit, kill with confirmation, and quit:
    ...
    (gdb) monitor exit
    (gdb) kill
    Kill the program being debugged? (y or n) y
    Remote connection closed
    (gdb) quit
    $
    ...

    But when doing monitor exit followed by quit with confirmation, we get the
gdb
    prompt back, requiring us to do quit once more:
    ...
    (gdb) monitor exit
    (gdb) quit
    A debugging session is active.

            Inferior 1 [process 16944] will be killed.

    Quit anyway? (y or n) y
    Remote connection closed
    (gdb) quit
    $
    ...

    So, the first quit didn't quit.  This happens as follows:
    - quit_command calls query_if_trace_running
    - a TARGET_CLOSE_ERROR is thrown
    - it's caught in remote_target::get_trace_status, but then
      rethrown because it's TARGET_CLOSE_ERROR
    - catch_command_errors catches the error, at which point the quit command
      has been aborted.

    The TARGET_CLOSE_ERROR is defined as:
    ...
      /* Target throwing an error has been closed.  Current command should be
         aborted as the inferior state is no longer valid.  */
      TARGET_CLOSE_ERROR,
    ...
    so in a way this is expected behaviour.  But aborting quit because the
inferior
    state (which we've already confirmed we're not interested in) is no longer
    valid, and having to type quit again seems pointless.

    Furthermore, the purpose of not catching errors thrown by
    query_if_trace_running as per commit 2f9d54cfcef ("make -gdb-exit call
    disconnect_tracing too, and don't lose history if the target errors on
    "quit""), was to make sure that error (_("Not confirmed.") had effect.

    Fix this in quit_command by catching only the TARGET_CLOSE_ERROR exception
    during query_if_trace_running and reporting it:
    ...
    (gdb) monitor exit
    (gdb) quit
    A debugging session is active.

            Inferior 1 [process 19219] will be killed.

    Quit anyway? (y or n) y
    Remote connection closed
    $
    ...

    Tested on x86_64-linux.

    PR server/15746
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15746
    Approved-By: Tom Tromey <tom@tromey.com>

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