From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28060 invoked by alias); 1 Jul 2008 11:38:17 -0000 Received: (qmail 28049 invoked by uid 22791); 1 Jul 2008 11:38:16 -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; Tue, 01 Jul 2008 11:37:42 +0000 Received: (qmail 24928 invoked from network); 1 Jul 2008 11:37:40 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Jul 2008 11:37:40 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: How to catch GDB crash Date: Tue, 01 Jul 2008 11:38:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb@sourceware.org, Dmitry Smirnov References: <200806241829.29427.pedro@codesourcery.com> <200806260027.59248.pedro@codesourcery.com> In-Reply-To: <200806260027.59248.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807011537.35321.vladimir@codesourcery.com> 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/msg00003.txt.bz2 On Thursday 26 June 2008 03:27:58 Pedro Alves wrote: > 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 ... I think that for the time being, we can change the assert to check that either the program is single-threaded, or the thread is known. If the program is single-threaded, the the thread id is not registered, omitting thread-id completely seems right. I can make this change, or you have something already? - Volodya