This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:",).

Philippe


(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.
Timed out.
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: O54686520666f6c6c6f77696e67206d6f6e69746f7220636f6d6d616e64732061726520737570706f727465643a0a
Unknown remote qXfer reply: O54686520666f6c6c6f77696e67206d6f6e69746f7220636f6d6d616e64732061726520737570706f727465643a0a
(gdb) info auxv
Sending packet: $qXfer:auxv:read::0,1000#6b...Packet received: O2020736574206465627567203c307c313e0a
Unknown remote qXfer reply: O2020736574206465627567203c307c313e0a
(gdb)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]