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$
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$
I ran into this recently as well.
(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.
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 $ ...
https://sourceware.org/pipermail/gdb-patches/2022-November/193414.html
https://sourceware.org/git/?p=binutils-gdb.git;a=search;s=Tom+de+Vries;st=author
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>