From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8656 invoked by alias); 21 Feb 2006 20:28:39 -0000 Received: (qmail 8648 invoked by uid 22791); 21 Feb 2006 20:28:38 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 21 Feb 2006 20:28:37 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FBe7d-0007vY-Kf; Tue, 21 Feb 2006 15:28:33 -0500 Date: Tue, 21 Feb 2006 20:43:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: sjackman@gmail.com, gdb-patches@sourceware.org Subject: Re: Fix a crash when stepping and unwinding fails Message-ID: <20060221202833.GA30161@nevyn.them.org> Mail-Followup-To: Mark Kettenis , sjackman@gmail.com, gdb-patches@sourceware.org References: <20060220220331.GA29363@nevyn.them.org> <200602212015.k1LKFGrj005090@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602212015.k1LKFGrj005090@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00404.txt.bz2 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. 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. > Seems like the problem is that the code > uses get_prev_frame(), which can return NULL, even if we could unwind, > for example when we try to unwind past main. Looks to me the real bug > here is that we're using get_prev_frame(). The right solution is > probably to use frame_pc_unwind(), and insert a the step resume > breakpoint there. That should never fail. > > This would probably demand us to introduce > insert_step_resume_breakpoint_at_pc(), and we could probably eliminate > insert_step_resume_breakpoint_at_frame() altogether. An alternative > would be to export get_prev_name_1() from frame.c (giving it a more > useful name). 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. -- Daniel Jacobowitz CodeSourcery