From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22612 invoked by alias); 7 Jul 2008 14:29:26 -0000 Received: (qmail 22602 invoked by uid 22791); 7 Jul 2008 14:29:25 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Jul 2008 14:29:05 +0000 Received: (qmail 28606 invoked from network); 7 Jul 2008 14:29:03 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Jul 2008 14:29:03 -0000 From: Pedro Alves To: gdb@sourceware.org, Dmitry Smirnov Subject: Re: How to catch GDB crash Date: Mon, 07 Jul 2008 14:29:00 -0000 User-Agent: KMail/1.9.9 References: <200807050414.43765.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807071528.57718.pedro@codesourcery.com> 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/msg00040.txt.bz2 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