From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27695 invoked by alias); 21 Feb 2006 20:51:43 -0000 Received: (qmail 27679 invoked by uid 22791); 21 Feb 2006 20:51:42 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Feb 2006 20:51:41 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k1LKox85032015; Tue, 21 Feb 2006 21:50:59 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k1LKowbs031735; Tue, 21 Feb 2006 21:50:58 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k1LKowmP012208; Tue, 21 Feb 2006 21:50:58 +0100 (CET) Date: Tue, 21 Feb 2006 20:54:00 -0000 Message-Id: <200602212050.k1LKowmP012208@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: sjackman@gmail.com, gdb-patches@sourceware.org In-reply-to: <20060221202833.GA30161@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 21 Feb 2006 15:28:33 -0500) Subject: Re: Fix a crash when stepping and unwinding fails References: <20060220220331.GA29363@nevyn.them.org> <200602212015.k1LKFGrj005090@elgar.sibelius.xs4all.nl> <20060221202833.GA30161@nevyn.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00408.txt.bz2 > Date: Tue, 21 Feb 2006 15:28:33 -0500 > From: Daniel Jacobowitz > > On Tue, Feb 21, 2006 at 09:15:16PM +0100, Mark Kettenis wrote: > > > It's still not great, but at least it's an improvement over crashing. > > > It is reasonably likely that we've just stepped over a standard > > > function call, and that consequentially the function return > > > address is in the standard place for the architecture; in fact, > > > GDB used to have a hook for this, before the frame overhaul: > > > SAVED_PC_AFTER_CALL. But it's gone now and there's no easy analogue, > > > and it was never 100% reliable anyway. So unfortunately, if we > > > single-step out to an address that we can't find a way to unwind from, > > > we'll stop instead of stepping out. > > > > How can this happen? Both affected calls to > > insert_step_resume_breakpoint_at_frame() are in the same > > > > if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id)) > > { > > > > block. Assuming that step_frame_id isn't equal to null_frame_id, this > > means that we *can* unwind. > > There's your problem: you're assuming that step_frame_id isn't equal to > null_frame_id. But in fact it is. But if step_frame_id is equal to null_frame_id, we shouldn't be trying to insert step-resume-breakpoints. It means that step_frame_id is still uninitialized, since step_frame_id is initialized by: step_frame_id = get_frame_id (get_current_frame ()); (or equivalent code), and unwinding from sentinel frame shoud always yield a frame ID that's different from null_frame_id. > If we can't unwind past the current frame, then that means the last > frame sniffer (generally the prologue analyzer), which is required > to accept any frame given to it, could not make heads or tails of > it. Which in turn means it doesn't know what the frame's ID is, so > it gets left as invalid. Which means the current frame will have an > ID of null_frame_id. > > That's what's happening to me, although I seem to recall something > similar could be produced by stepping across main without debug info. I think it can happen if you're trying to step "over" main from within the C runtime code. But in that case the frame ID won't be null_frame_id. > That seems like a good change indeed, but probably wouldn't fix this > problem. > > Hmm, what does frame_pc_unwind do when we've hit the last frame? I'm > not sure it's meaningful. How can we hit the last frame? If we're hitting the last frame, where did we come from? It may very well be that there are GDB bugs that make step_frame_id equal to null_frame_id. If we can't trace those bugs right now, we should probably sprinkle a few gdb_assert()'s around and try to solve the issues when we hit those. Mark