Re[2]: How to catch GDB crash

[Dmitry Smirnov <divis1969 at mail dot ru>]

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 <main>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 <pedro@codesourcery.com>
To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
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)
>