This is the mail archive of the
mailing list for the GDB project.
gdbserver/gdb cannot resync remote protocol after a timeout
- From: "Philippe Waroquiers" <philippe dot waroquiers at skynet dot be>
- To: <gdb at sourceware dot org>
- Date: Tue, 21 Jun 2011 22:58:46 +0200
- Subject: gdbserver/gdb cannot resync remote protocol after a timeout
If ever the remote timeout expires between gdb and gdbserver, then after that,
gdb cannot properly resynchronise anymore the queries and the replies.
(problem initially encountered with a Valgrind gdbserver "monitor mc.leak_check"
monitor command, which can take some time for large heap to check).
I have reproduced this by inserting a line
poll(NULL, 0, 10000);
at the beginning of the function monitor_show_help() of the gdbserver of gdb.
Then "monitor help" reproduces the same de-synchronisation.
See below the packets trace. After the timeout, any query packet gets
an error (or get back the reply of a previous packet).
I know that the timeout can be configured, but if when this timeout expires,
gdb can't resync, what is the reason to have a timeout ?
Or maybe the "desync" only happens in noack mode ? Then in noack mode,
the timeout value should better be always ignored.
In case there was a timeout, shouldn't gdb first "drop all packets it can"
before launching another command ?
This would resync after a timeout.
Alternatively, the "qRcmd" could be made "less time sensitive", either by
looping on getpkt_sane till the user types Control-c
or by temporarily increase the timeout (like "vFlashWrite:",).
(gdb) tar rem :1234
Remote debugging using :1234
warning: Can not parse XML target description; XML support was disabled at compile time
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
0xb7730850 in ?? () from /lib/ld-linux.so.2
Created trace state variable $trace_timestamp for target's variable 1.
(gdb) set debug remote 1
(gdb) monitor help
Sending packet: $qRcmd,68656c70#fc...Timed out.
Ignoring packet error, continuing...
Reply contains invalid hex digit 116
(gdb) info auxv
Sending packet: $qXfer:auxv:read::0,1000#6b...Packet received:
Unknown remote qXfer reply: O54686520666f6c6c6f77696e67206d6f6e69746f7220636f6d6d616e64732061726520737570706f727465643a0a
(gdb) info auxv
Sending packet: $qXfer:auxv:read::0,1000#6b...Packet received: O2020736574206465627567203c307c313e0a
Unknown remote qXfer reply: O2020736574206465627567203c307c313e0a