From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18823 invoked by alias); 29 Jul 2004 22:56:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18816 invoked from network); 29 Jul 2004 22:56:56 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Jul 2004 22:56:56 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6TMuue3007153 for ; Thu, 29 Jul 2004 18:56:56 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6TMuta17946; Thu, 29 Jul 2004 18:56:55 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 07CB02B9D; Thu, 29 Jul 2004 18:56:51 -0400 (EDT) Message-ID: <410980B2.3060308@gnu.org> Date: Thu, 29 Jul 2004 22:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: gdb_assert will never be triggered References: <20040722023907.GV1278@gnat.com> <40FF325F.6030207@gnu.org> <20040722032458.GW1278@gnat.com> In-Reply-To: <20040722032458.GW1278@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00468.txt.bz2 >>>It looks like the assertion will always be true, due to the block >>>> >above... Do we want to keep this gdb_assert() call nonetheless? >> >>> >>> Yes. Can you post the snipped comments (both of them :-). > > > Here is everything: (catching up with the backlog) Right. PREV_FRAME should never be NULL. Unfortunatly breakage elsewhere means that it occasionally is :-( If we fix the breakage we can delete that if() and then the assert will make sense :-) Andrew > /* Return the inner-most frame, when the caller passes in NULL. */ > /* NOTE: cagney/2002-11-09: Not sure how this would happen. The > caller should have previously obtained a valid frame using > get_selected_frame() and then called this code - only possibility > I can think of is code behaving badly. > > NOTE: cagney/2003-01-10: Talk about code behaving badly. Check > block_innermost_frame(). It does the sequence: frame = NULL; > while (1) { frame = get_prev_frame (frame); .... }. Ulgh! Why > it couldn't be written better, I don't know. > > NOTE: cagney/2003-01-11: I suspect what is happening in > block_innermost_frame() is, when the target has no state > (registers, memory, ...), it is still calling this function. The > assumption being that this function will return NULL indicating > that a frame isn't possible, rather than checking that the target > has state and then calling get_current_frame() and > get_prev_frame(). This is a guess mind. */ > if (this_frame == NULL) > { > /* NOTE: cagney/2002-11-09: There was a code segment here that > would error out when CURRENT_FRAME was NULL. The comment > that went with it made the claim ... > > ``This screws value_of_variable, which just wants a nice > clean NULL return from block_innermost_frame if there are no > frames. I don't think I've ever seen this message happen > otherwise. And returning NULL here is a perfectly legitimate > thing to do.'' > > Per the above, this code shouldn't even be called with a NULL > THIS_FRAME. */ > frame_debug_got_null_frame (gdb_stdlog, this_frame, "this_frame NULL"); > return current_frame; > } > > /* There is always a frame. If this assertion fails, suspect that > something should be calling get_selected_frame() or > get_current_frame(). */ > gdb_assert (this_frame != NULL); > >>>>> > > > -- Joel