From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4726 invoked by alias); 26 Jun 2008 14:33:18 -0000 Received: (qmail 4714 invoked by uid 22791); 26 Jun 2008 14:33:16 -0000 X-Spam-Check-By: sourceware.org Received: from f99.mail.ru (HELO f99.mail.ru) (194.67.57.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jun 2008 14:32:56 +0000 Received: from mail by f99.mail.ru with local id 1KBsWk-000OcR-00; Thu, 26 Jun 2008 18:32:46 +0400 Received: from [212.92.145.7] by win.mail.ru with HTTP; Thu, 26 Jun 2008 18:32:46 +0400 From: Dmitry Smirnov To: Pedro Alves Cc: 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: Thu, 26 Jun 2008 14:33:00 -0000 In-Reply-To: <200806261520.54671.pedro@codesourcery.com> References: <200806261520.54671.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/msg00277.txt.bz2 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. :-) > > I'm hoping to get to commit them today, though... > > > Below is a new log of my debug session. I've set the same > > mi_execute_command and mi_on_resume. Last one prints the value of > > 'inferior_ptid' when hit. Also, from Eclipse I've issues command 'ni' > > before 'c'. As you can see, 'inferior_ptid' it is equal to {pid = 42000, > > lwp = 0, tid = 0} all the time whereas mi_on_resume is called with {pid = > > -1, lwp = 0, tid = 0} in all cases except last one. > > > > On my mind it indicates that while executing last 'ni', function resume() > > in file infrun.c goes different way and it assigned 'inferior_ptid' to > > 'resume_ptid' instead of default RESUME_ALL. > > Did you actually look at the function that is asserting? Here it is again: > > static void > mi_on_resume (ptid_t ptid) > { > if (PIDGET (ptid) == -1) > fprintf_unfiltered (raw_stdout, "*running,thread-id=\"all\"\n"); > else > { > struct thread_info *ti = find_thread_pid (ptid); > gdb_assert (ti); > fprintf_unfiltered (raw_stdout, "*running,thread-id=\"%d\"\n", ti->num); > } > } > > Calling the resume functions with {-1,0,0} means "let all threads execute", > while with {42000,0,0} meant, "let only this thread execute". This last > case happens normally when GDB is trying to step over a breakpoint: > > - remove breakpoints > - step only the thread of interest, leaving others stopped, so if they happen > to be executing the same code, they don't miss the breakpoint > - reinsert breakpoints > - now safe to resume all threads > > It just happens that in your case there's only one "thread" always, > but the core of inferior control in GDB doesn't care and sends {42000,0,0} > anyway. The problem was that this assert is there because this function > assumes threads are always registered in the thread table, while that > is unfortunatelly still not always true throughout all of GDB's supported > targets. > > > Breakpoint 1, mi_on_resume (ptid={pid = 42000, lwp = 0, tid = 0}) > > at .././gdb/mi/mi-interp.c:335 > > 335 if (PIDGET (ptid) == -1) > > $3 = {pid = 42000, lwp = 0, tid = 0} > > > > Program exited with code 037777777777. > > (gdb) > > -- > Pedro Alves >