From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32510 invoked by alias); 21 Feb 2006 20:15:58 -0000 Received: (qmail 32501 invoked by uid 22791); 21 Feb 2006 20:15:57 -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:15:54 +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 k1LKFHJR013686; Tue, 21 Feb 2006 21:15:17 +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 k1LKFH6k006515; Tue, 21 Feb 2006 21:15:17 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k1LKFGrj005090; Tue, 21 Feb 2006 21:15:16 +0100 (CET) Date: Tue, 21 Feb 2006 20:28:00 -0000 Message-Id: <200602212015.k1LKFGrj005090@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: sjackman@gmail.com, gdb-patches@sourceware.org In-reply-to: <20060220220331.GA29363@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 20 Feb 2006 17:03:31 -0500) Subject: Re: Fix a crash when stepping and unwinding fails References: <20060220220331.GA29363@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/msg00403.txt.bz2 > Date: Mon, 20 Feb 2006 17:03:31 -0500 > From: Daniel Jacobowitz > > This patch stops GDB from segfaulting when we step into a function, > but can not unwind back out of the function. We would previously > call get_prev_frame, which would return NULL, and then try to > get_frame_pc (NULL). > > Now we'll issue this error instead, and stop stepping: > > Could not step out of the function at 0x80144400 - unwinding failed > > 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. 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). I must say, I don't really liked the way you changed the insert_step_resume_breakpoint_at_frame() interface. That extra USE_PREVIOUS argument is really awkward, and made the function name rather non-sensible. Mark