From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10456 invoked by alias); 2 Jul 2008 11:05:53 -0000 Received: (qmail 10442 invoked by uid 22791); 2 Jul 2008 11:05:52 -0000 X-Spam-Check-By: sourceware.org Received: from f137.mail.ru (HELO f137.mail.ru) (194.67.57.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jul 2008 11:05:31 +0000 Received: from mail by f137.mail.ru with local id 1KE09Q-000L4A-00 for gdb@sourceware.org; Wed, 02 Jul 2008 15:05:28 +0400 Received: from [212.92.145.7] by win.mail.ru with HTTP; Wed, 02 Jul 2008 15:05:28 +0400 From: Dmitry Smirnov To: gdb@sourceware.org Subject: =?koi8-r?Q?Re=3A_How_to_catch_GDB_crash?= Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 Date: Wed, 02 Jul 2008 11:05:00 -0000 References: In-Reply-To: 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/msg00011.txt.bz2 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
" * 1 Thread
&"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 , 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 , 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 , 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 , 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 , 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 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 > To: Pedro Alves > 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 > > To: gdb@sourceware.org, Dmitry Smirnov > > 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. :-) > > > >