From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26928 invoked by alias); 26 Jun 2008 14:21:16 -0000 Received: (qmail 26911 invoked by uid 22791); 26 Jun 2008 14:21:15 -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; Thu, 26 Jun 2008 14:20:56 +0000 Received: (qmail 17075 invoked from network); 26 Jun 2008 14:20:54 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jun 2008 14:20:54 -0000 From: Pedro Alves To: gdb@sourceware.org, Dmitry Smirnov Subject: Re: How to catch GDB crash Date: Thu, 26 Jun 2008 14:21:00 -0000 User-Agent: KMail/1.9.9 References: <200806260027.59248.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: <200806261520.54671.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/msg00275.txt.bz2 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