From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30744 invoked by alias); 21 Jun 2011 20:59:05 -0000 Received: (qmail 30730 invoked by uid 22791); 21 Jun 2011 20:59:04 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailrelay004.isp.belgacom.be (HELO mailrelay004.isp.belgacom.be) (195.238.6.170) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Jun 2011 20:58:48 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkHAJ8DAU5tgOfT/2dsb2JhbABUiheOF45SeIhsCaAUn0wOhhwEoW4 Received: from 211.231-128-109.adsl-dyn.isp.belgacom.be (HELO soleil) ([109.128.231.211]) by relay.skynet.be with SMTP; 21 Jun 2011 22:58:46 +0200 Message-ID: <367727AC632C495DB8E64FEE16ADAD75@soleil> From: "Philippe Waroquiers" To: Subject: gdbserver/gdb cannot resync remote protocol after a timeout Date: Tue, 21 Jun 2011 20:59:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00136.txt.bz2 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)