This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Host GDB disconnect while waiting for tracee status change
- From: Dmitry Antipov <dantipov at nvidia dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: <gdb at sourceware dot org>, Ryan Bissell <rbissell at nvidia dot com>, "Mikhail Filimonov" <mfilimonov at nvidia dot com>
- Date: Wed, 23 Aug 2017 12:37:15 +0300
- Subject: Re: Host GDB disconnect while waiting for tracee status change
- Authentication-results: sourceware.org; auth=none
- References: <5febbe3e-926f-78bb-db88-901b44e2e258@nvidia.com> <867exusnn8.fsf@gmail.com>
On 08/23/2017 11:18 AM, Yao Qi wrote:
I didn't try GDBserver under the case you described, but I find
something related int GDB manual,
https://sourceware.org/gdb/onlinedocs/gdb/Server.html
"Therefore, when the connection drops unexpectedly, and GDB cannot ask
gdbserver to kill its debugged processes, gdbserver stays running even
in the target remote mode."
It's definitely stays running, but seems doesn't listen for remote connection
attempts anymore. For example:
$ cat /tmp/t-simple.c
int main (int argc, char *argv[]) { while (1) (void) argc; return 0; }
$ gdbserver --debug --attach tcp:9999 $(pidof t-simple)
$ gdb -q
(gdb) target extended-remote :9999
Remote debugging using :9999
[...skipped...]
0x00000000004004f2 in main (argc=1, argv=0x7ffec6b6b208) at /tmp/t-simple.c:1
1 int main (int argc, char *argv[]) { while (1) (void) argc; return 0; }
(gdb) c
Continuing.
Segmentation fault (core dumped) ;; Due to killall -11 gdb from another TTY
Immediately after killing gdb, gdbserver reports:
...
client connection closed
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x40000001): status(ffffffff), 0
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
leader_pid=21352, leader_lp!=NULL=1, num_lwps=1, zombie=0
sigsuspend'ing
...
Next, a new instance of gdb is unable to reconnect:
$ gdb -q
(gdb) target extended-remote :9999
Remote debugging using :9999
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
And it seems that there is no similar issue in a non-stop mode. For example:
$ gdb -q
(gdb) set non-stop 1
(gdb) target extended-remote :9999
Remote debugging using :9999
[...skipped...]
Program stopped.
0x00000000004004f2 in main (argc=1, argv=0x7ffc72333088) at /tmp/t-simple.c:1
1 int main (int argc, char *argv[]) { while (1) (void) argc; return 0; }
(gdb) c
Continuing.
Segmentation fault (core dumped) ;; Due to killall -11 gdb from another TTY
Immediately after killing gdb, gdbserver reports:
...
handling possible serial event
Remote side has terminated connection. GDBserver will reopen the connection.
Listening on port 9999
...
This way, a new instance of gdb can reconnect:
$ gdb -q
(gdb) set non-stop 1
(gdb) target extended-remote :9999
Remote debugging using :9999
[...skipped...]
(gdb) interrupt
Program stopped.
0x00000000004004f2 in main (argc=1, argv=0x7ffc72333088) at /tmp/t-simple.c:1
1 int main (int argc, char *argv[]) { while (1) (void) argc; return 0; }
(gdb)
Dmitry