From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14323 invoked by alias); 25 Jun 2008 08:03:03 -0000 Received: (qmail 14311 invoked by uid 22791); 25 Jun 2008 08:03:02 -0000 X-Spam-Check-By: sourceware.org Received: from f62.mail.ru (HELO f62.mail.ru) (194.67.57.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jun 2008 08:02:40 +0000 Received: from mail by f62.mail.ru with local id 1KBPxZ-0008HB-00 for gdb@sourceware.org; Wed, 25 Jun 2008 12:02:33 +0400 Received: from [212.92.145.7] by win.mail.ru with HTTP; Wed, 25 Jun 2008 12:02:33 +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, 25 Jun 2008 08:03:00 -0000 References: <200806241829.29427.pedro@codesourcery.com> In-Reply-To: <200806241829.29427.pedro@codesourcery.com> 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-06/txt/msg00248.txt.bz2 Hi Pedro, I'll try to figure out, whether skyeye (which is remote target) supports notion of thread ids or pids. Now I just suppose it does not support. Nevertheless, I do not believe this is related to a crash. As I said previously, I was debugging this program (ARM code) for some time previously. It is very complex program, it consists of several ELF files. Before this one, I've debugged couple more. I've used 'ni' and/or -exec-next-instruction a lot and didn't see a lot crashes. I remember that I've seen couple of them (in similar scenario: when I've set a BP and run till it hits) but I had eliminated it by moving the breakpoint to another location. It is just feeling, no more, that crash is somehow connected with stack trace: previously I didn't see much stack traces. In most cases there was 2 or 3 frames (in fact, call stack should have more frames, but GDB was not able to correctly detect frames. This may be caused by assembler code which does not follow ABI). BTW, I've just realized that command-line interface does not use mi_* interface (neither mi_on_resume nor mi_execute_command were hit) and this is most likely the reason why I cannot reproduce this test case with CLI. Dmitry -----Original Message----- From: Pedro Alves To: gdb@sourceware.org, Dmitry Smirnov Date: Tue, 24 Jun 2008 18:29:28 +0100 Subject: Re: How to catch GDB crash > > A Tuesday 24 June 2008 18:02:49, Dmitry Smirnov wrote: > > As you can see, first time > > mi_on_resume is called with ptid={pid = -1, lwp = 0, tid = 0}. Something > > happens between this call and second call where ptid={pid = 42000, lwp = 0, > > tid = 0}. > > > > I'm going to figure out which command is followed by wrong pid. I'm > > suspecting memory corruption. > > This pid is used by GDB internally when you are connected to a target > that does not support threads at all, like small embedded systems. > If the remote side doesn't have a notion of thread ids or pids, that > magic number is what GDB will use internally. This code path can > be triggered for example while stepping over a breakpoint (doing > nexti / -exec-next-instruction while stopped at a breakpoint). > > > BTW, command 'info threads' gives me > > (gdb) info threads > > warning: RMT ERROR : failed to get remote thread list. > > ... which this seems to corroborate. > > This is a new bug in GDB that was introduced recently. > > I've already said in my last reply what needs to be done > to fix it. > > If your target *does* support threads and the remote protocol > thread related packets, than there's yet another bug somewhere > else. > > -- > Pedro Alves >