From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1726 invoked by alias); 2 Jul 2008 12:51:06 -0000 Received: (qmail 1690 invoked by uid 22791); 2 Jul 2008 12:51:05 -0000 X-Spam-Check-By: sourceware.org Received: from f136.mail.ru (HELO f136.mail.ru) (194.67.57.117) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jul 2008 12:50:04 +0000 Received: from mail by f136.mail.ru with local id 1KE1ma-000JUp-00; Wed, 02 Jul 2008 16:50:00 +0400 Received: from [212.92.145.7] by win.mail.ru with HTTP; Wed, 02 Jul 2008 16:50:00 +0400 From: Dmitry Smirnov To: Pedro Alves , gdb@sourceware.org Subject: =?koi8-r?Q?Re[2]=3A_How_to_catch_GDB_crash?= Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 Date: Wed, 02 Jul 2008 12:51:00 -0000 References: <200807021252.15748.pedro@codesourcery.com> In-Reply-To: <200807021252.15748.pedro@codesourcery.com> Reply-To: Dmitry Smirnov Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: OK 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: 2008-07/txt/msg00013.txt.bz2 Hi Pedro, Here is the log: (gdb) set debug remote 1 (gdb) info threads Sending packet: $qL1160000000000000000#55...Ack Packet received: warning: RMT ERROR : failed to get remote thread list. Sending packet: $qThreadExtraInfo,ffffffff#b5...Ack Packet received: T1 * 1 Thread
Reply contains invalid hex digit 84 I'm wondering why GDB is trying to get ThreadExtraInfo if stub has responded that it does not support threads? BTW, I didn't see this "Reply contains invalid hex digit 84" in older GDBs. Does stub HAVE to support it? P.S. I'll test your patch a little bit later and come back with results. Dmitry -----Original Message----- From: Pedro Alves To: gdb@sourceware.org, Dmitry Smirnov Date: Wed, 2 Jul 2008 12:52:15 +0100 Subject: Re: How to catch GDB crash > > Hi Dmitry, thanks for taking the time to investigate deeper. > > A Wednesday 02 July 2008 12:05:28, Dmitry Smirnov wrote: > > Hi, > > > > Regarding the problem of -exec-run, I've suspended its investigation: I've > > found that 6.8.50.20080630 just didn't respond "running" and this seems > > reasonable. So, perhaps, previous version is misbehaving so causing Eclipse > > behave wrong way. Though, it is not clear why gdbServer CDT debugger also > > fails. Just postponed... > > > > I don't know what to say about this failure. The command was already > failing before, but it was outputting a spurious "^running". Why is > eclipse even trying to run a process in with "target remote", I don't know. > > > I've found another Eclipse CDT debugger variant that can run as I wish. > > And here I have a problem that I was reported to Pedro earlier: Eclipse is > > unable to disassemble the code, show variables, etc. > > > > I've noticed that GDB respond to "info threads" contains an error message. > > Below is the stack dump of this situation. I'm suspecting this respond > > prevents Eclipse from doing right. > > What is that "T1"? > > I don't know. It looks like a bug in the stub/simulator. > Do you have a way to activate remote protocol debugging? > "set debug remote 1" is the GDB command to use. > The stub embedded in the simulator you're using doesn't seem to > support any other thread related packets, and I would expect > it to reply "" to this packet too. > > In the mean time, I think the attached patch (untested other than > building it) is sensible. Could you give it a try? > > -- > Pedro Alves > > ATTACHMENT: text/x-diff (dont_query_internal_threads.diff) >