From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15181 invoked by alias); 25 Jun 2008 23:28:21 -0000 Received: (qmail 15172 invoked by uid 22791); 25 Jun 2008 23:28:20 -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; Wed, 25 Jun 2008 23:28:02 +0000 Received: (qmail 10551 invoked from network); 25 Jun 2008 23:28:00 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jun 2008 23:28:00 -0000 From: Pedro Alves To: gdb@sourceware.org, Dmitry Smirnov , Vladimir Prus Subject: Re: How to catch GDB crash Date: Wed, 25 Jun 2008 23:28:00 -0000 User-Agent: KMail/1.9.9 References: <200806241829.29427.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: <200806260027.59248.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-06/txt/msg00264.txt.bz2 A Wednesday 25 June 2008 09:02:33, Dmitry Smirnov wrote: > 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. Yes it is. :-) > > As I said previously, I was debugging this program (ARM code) for some time > previously. But you've certainly upgraded your GDB recently (I can tell by your log output on your original post). As I said, this is a recently introduced regression. I've was able to reproduce the problem, by connecting to a local gdbserver with a GDB with all thread support hacked out in the remote target. > 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. > Yes, that's exactly the reason. Anyway, I've posted a patch that fixes the issue in your case (it was actually a side effect of something else I was doing), although we may need to get rid of the assert you weren't tripping at for the time being (there are other targets other than remote that will also trip on the assert). Vladimir, not sure if you noticed the issue, as it's buried in this long thread? We can always leave the crash in place to force targets to follow our evil plot of always registering the main thread. :-) I'd post a patch for it, but I don't know if we should output thread-id=0 in that case, or not output thread-id at all ... -- Pedro Alves