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]

Re: How to catch GDB crash


A Monday 07 July 2008 09:35:43, Dmitry Smirnov wrote:
> Didn't have much time to digger.
> It seems that Eclipse CDT debugger is confused with the delayed "running"
> response. 

Oh, sorry if I didn't make it clear.  This patch was to fix the "info threads"
issue you found, not the "^running" problem.

> CDT can connect to the remote debugger, retireve stack (it is 
> absent at this point, in fact), retrieve variables, disassebling. But when
> I try to run it ("-exec-continue") there is nothing responded from gdb
> (i.e. "running" until it hits the breakpoint. Since in my case, it takes
> significant time to get to BP, Eclipse decides that target is not
> responding and either terminates ("gdbServer" CDT debugger) or behaves
> oddly ("Hardware" CDT Debugger): it sends commands like usual but do not
> show retrieved data (gdb itself responses correctly).
>

I think you said earlier that when you switched to the other eclipse you
had around that got over the "^running" problem, you weren't even able
to inspect the stack or do any disassembling --  eclipse would get
stuck on the "info threads" command.  I take it that since you
report you can now retrieve variables etc, that the "info threads"
issue is fixed?  I'll post this patch for review at gdb-patches@.

Thanks,

-- 
Pedro Alves


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