Re: How to catch GDB crash

[Dmitry Smirnov <divis1969 at mail dot ru>]

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'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"?
JIC, here is the console log of Eclipse:
 
&"info threads\n"
Reply contains invalid hex digit 84
info threads
&"warning: RMT ERROR : failed to get remote thread list.\n"
warning: RMT ERROR : failed to get remote thread list.
Reply contains invalid hex digit 84
~"* 1 Thread <main>"
* 1 Thread <main>&"Reply contains invalid hex digit 84\n"
553^error,msg="Reply contains invalid hex digit 84"


Breakpoint 1, fromhex (a=84) at remote.c:3007
3007        error (_("Reply contains invalid hex digit %d"), a);
(gdb) bt
#0  fromhex (a=84) at remote.c:3007
#1  0x004ea0db in hex2bin (hex=0x1004ace8 "T1", bin=0x697701 "", count=1)
    at remote.c:3023
#2  0x004ebe3a in remote_threads_extra_info (tp=0x1170cc60) at remote.c:2054
#3  0x0047c53f in print_thread_info (uiout=0x1006b278, requested_thread=-1)
    at thread.c:537
#4  0x00402473 in execute_command (p=0x22c6bc "", from_tty=1) at top.c:466
#5  0x00411722 in catch_exception (uiout=0x1006b278,
    func=0x48e3c0 <do_captured_execute_command>, func_args=0x22c6d8, mask=6)
    at exceptions.c:463
#6  0x0048e466 in cli_interpreter_exec (data=0x0,
    command_str=0x10ed21c0 "info threads") at .././gdb/cli/cli-interp.c:130
#7  0x0041ad3b in interp_exec (interp=0x1006b2e0,
    command_str=0x10ed21c0 "info threads") at interps.c:325
#8  0x0048cf39 in mi_cmd_interpreter_exec (
    command=0x64d5fb "-interpreter-exec", argv=0x22c7d8, argc=2)
    at .././gdb/mi/mi-interp.c:209
#9  0x0050626a in captured_mi_execute_command (uiout=0x1006bc58,
    data=0x11572ce0) at .././gdb/mi/mi-main.c:974
#10 0x00411722 in catch_exception (uiout=0x1006bc58,
    func=0x505f30 <captured_mi_execute_command>, func_args=0x11572ce0, mask=6)
    at exceptions.c:463
#11 0x00505d23 in mi_execute_command (cmd=0x1170ccb8 "551 info threads",
    from_tty=1) at .././gdb/mi/mi-main.c:1026
#12 0x0048d019 in mi_execute_command_wrapper (
    cmd=0x1170ccb8 "551 info threads") at .././gdb/mi/mi-interp.c:254
#13 0x0043703a in handle_file_event (event_file_desc=0) at event-loop.c:732
#14 0x00436aa2 in process_event () at event-loop.c:341
#15 0x00437385 in gdb_do_one_event (data=0x0) at event-loop.c:378
#16 0x0041196b in catch_errors (func=0x437200 <gdb_do_one_event>,
    func_args=0x0, errstring=0x607b30 "", mask=6) at exceptions.c:509
#17 0x00436af4 in start_event_loop () at event-loop.c:404
#18 0x004010ab in captured_command_loop (data=0x0) at .././gdb/main.c:104
#19 0x0041196b in catch_errors (func=0x4010a0 <captured_command_loop>,
    func_args=0x0, errstring=0x5f7139 "", mask=6) at exceptions.c:509
#20 0x00401c94 in captured_main (data=0x22cc40) at .././gdb/main.c:891
#21 0x0041196b in catch_errors (func=0x4010f0 <captured_main>,
    func_args=0x22cc40, errstring=0x5f7139 "", mask=6) at exceptions.c:509
#22 0x00402153 in gdb_main (args=0x22cc40) at .././gdb/main.c:900
#23 0x0040109b in main (argc=6, argv=0x1002aee8) at gdb.c:33

-----Original Message-----
From: Dmitry Smirnov <divis1969@mail.ru>
To: gdb@sourceware.org
Date: Mon, 30 Jun 2008 19:56:56 +0400
Subject: Re: How to catch GDB crash

> 
> Hi,
> 
> I've upgraded to gdb-6.8.50.20080630 and tested it.
> Unfortunately, I was totally unable to run my test case from Eclipse CDT.
> I've figured out that the problem is what GDB resonds to exec-run command.
> 
> Here is the Eclipse session log (it shows requests to GDB and responses)
> 
> 84-exec-run
> 84^error,msg="Don't know how to run.  Try \"help target\"."
> 
> I've tried older version of arm-elf-gdb (6.5):
> 
> 123-exec-run
> 123^running
> &"Don't know how to run.  Try \"help target\".\n"
> Don't know how to run.  Try "help target".
> 123^error,msg="Don't know how to run.  Try \"help target\"."
> 
> It seems that responses differs in 123^running (or maybe the order too?).
> 
> Is it possible to fix this?
> 
> Dmitry
> 
> 
> -----Original Message-----
> From: Dmitry Smirnov <divis1969@mail.ru>
> To: Pedro Alves <pedro@codesourcery.com>
> Date: Thu, 26 Jun 2008 18:32:46 +0400
> Subject: Re: How to catch GDB crash
> 
> > 
> > Ok, you'd convinced me :-)
> > You are right, the last resume() is executed with stepping_over_breakpoint equal to 1 whereas previously it was 0.
> > 
> > I'll try your patch (I can find it in gdb-patches, right?).
> > 
> > Dmitry
> > 
> > -----Original Message-----
> > From: Pedro Alves <pedro@codesourcery.com>
> > To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
> > Date: Thu, 26 Jun 2008 15:20:54 +0100
> > Subject: Re: How to catch GDB crash
> > 
> > > 
> > > A Thursday 26 June 2008 14:56:26, Dmitry Smirnov wrote:
> > > > I still have some doubts :-)
> > > >
> > > 
> > > Well, the doubts would go away if you tried the patches.  :-)
> > > 
>